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provide. 
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I.  BACKGROUND 


A.  INTRODUCTION 

This  thesis  describes  the  complete  development  process  of  a  fully  functional 
Intranet  for  an  operational  United  States  Coast  Guard  (USCG)  Electronic  Support  Unit 
(ESU)  in  Alameda,  California.  The  final  product  may  be  used  as  an  operational  Intranet 
for  the  ESU,  or  it  may  simply  be  a  prototype,  which  can  be  used  as  a  baseline  for  future 
development  efforts. 

The  Intranet  was  developed  in  seven  unique  stages  of  the  Waterfall  Model  of 
information  systems  design.  The  Waterfall  Model  traces  a  systems  development  lifecycle 
from  planning,  to  logical  design,  through  physical  design,  and  finally  ends  with  the 
implementation  process.  Each  stage  of  the  development  model  is  addressed  in  this  thesis. 

The  development  effort  resulted  in  a  complete  physical  product,  which  will  be 
delivered  to  the  customer.  The  discussion  will  concentrate  on  how  and  why  certain 
applications  were  developed,  how  they  are  intended  to  be  used,  and  what  business 
benefits  they  provide.  Both  the  management  aspects  and  the  technical  solutions  for  the 
Intranet  will  be  addressed. 

Intranet  technology  provides  a  radical  new  means  of  communicating  throughout 
an  organization.  The  product  of  this  thesis  is  a  well  designed  and  technically  solid, 
Intranet  tool  with  significant  potential  to  enhance,  improve  and  eliminate  current  ESU 
business  processes.  This  new  technology  has  the  potential  to  change  the  organization. 

The  final  success  or  failure  of  the  implementation  does  not  depend  solely  on  the 
technical  merits  of  the  system.  Instead,  the  social  aspects  of  introducing  a  powerful  new 
information  system  to  an  organization  must  be  considered.  The  way  the  change  is 
managed  will  determine  the  final  outcome  of  the  implementation  process.  The  results  of 
the  new  change  will  not  be  known  for  some  time. 

B.  CUSTOMER 

The  sponsoring  Command  was  United  States  Coast  Guard  Electronic  Support 
Unit  Alameda  (ESU).  ESU  Alameda’s  mission  is  to  provide  support  and  maintenance 
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resources  for  all  electronics,  telecommunications  and  computer  equipment  aboard  USCG 
units  in  the  Eleventh  Coast  Guard  District.  The  Eleventh  District  encompasses  the  entire 
State  of  California  as  well  as  any  USCG  units  requesting  assistance  while  in  California 
waters.  The  ESU  has  a  central  office  located  in  Alameda,  California  where  there  are 
about  50  full  time  employees.  ESU  Alameda  also  has  three  remote  ESU  Detachments 
which  are  located  in  San  Pedro,  San  Diego  and  Oxnard,  California. 

C.  OBJECTIVE 

The  thesis  objective  is  to  build  a  functional  prototype  Intranet.  The  customer  may 
find  many  different  ways  of  using  it.  The  possible  outcomes  from  the  implementation 
process  are  listed  here  in  order  of  increasing  success.  First,  the  Intranet  may  be 
considered  solely  as  a  prototype,  which  demonstrates  the  capabilities  of  Intranet 
technologies.  In  this  case,  it  would  rarely  be  used  in  daily  operations.  Next,  the  Intranet 
may  actually  be  integrated  and  used  in  the  ESU’s  daily  operations  as  a  fully  functional 
tool.  Finally,  it  may  be  both  an  operational  tool  as  well  as  a  prototype  that  is  maintained 
and  enhanced  at  the  ESU.  This  foundation  of  an  Intranet  may  grow  larger  over  time  as  the 
ESU  takes  ownership  of  it.  This  is  the  ideal  goal. 

In  all  cases,  the  ESU  will  benefit  from  this  thesis.  Their  Intranet  is  custom  built 
with  over  80  dynamically  generated  pages.  A  commercial  Web  site  costs  a  minimum  of 
$1000  for  a  basic  site,  designed  from  template,  with  a  maximum  of  20  static  pages 
(www.Interland.net).  The  ESU  Intranet  is  essentially  free.  Even  if  the  Intranet 
implementation  fails  over  the  long  term,  the  ESU  will  have  had  a  working  prototype  to 
test.  This  will  give  them  an  advantage  on  any  future  Intranet  requirements  determination 
cycle.  They  will  have  had  a  more  comprehensive  understanding  of  their  own  needs  and 
the  capabilities  of  the  technology. 

D.  INTRANET  DEFINED 

An  Intranet  is  simply  a  private  version  of  the  Internet.  Intranets  conveniently 
make  internal  company  information  available  to  all  employees  using  the  same  protocols 
and  technologies  that  make  the  World  Wide  Web  so  successful.  Where  the  Internet  is 
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global  in  reach,  an  Intranet  is  private  and  usually  access  is  either  physically  or  virtually 
restricted  to  a  particular  company’s  members.  An  Intranet  opens  the  channels  of 
communication  to  allow  sharing,  updating  and  querying  for  information  throughout  the 
network  without  regard  to  time  or  distance. 

The  minimum  requirements  for  an  Intranet  include  a  local  area  network,  a  Web 
Server,  Web  browsers,  and  Web  authoring  tools.  Intranet  information  is  typically 
displayed  on  Web  pages  in  a  client  terminal’s  Web  browser  window. 

E.  INTRANET  OBJECTIVE 

The  objective  of  the  Intranet  is  to  provide  a  technology  tool  that  will  add  value  to 
the  ESU’s  daily  operations.  The  Intranet  is  a  tool  that  should  be  incorporated  into  a 
broader  organizational  management  plan. 

The  goal  of  the  developer  was  to  address  the  Command’s  top  needs  with  Intranet 
solutions.  Analysis  of  the  ESU’s  business  model  uncovered  many  business  processes, 
which  could  benefit  from  Intranet  technologies.  Choices  had  to  be  made  about  which 
applications  were  most  feasible  and  which  would  actually  be  developed  for  the  ESU 
Intranet.  Availability  of  technology,  the  author's  expertise,  and  time  constraints  were 
limiting  factors  that  narrowed  the  scope  of  applications  development.  The  final  product 
successfully  addresses  aspects  of  two  major  concerns  of  the  ESU  Command,  personnel 
administration  and  supply  tracking.  Other  business  benefits,  such  as  remote  availability 
of  up-to-the  minute  dynamic  information  and  enhanced  communications  across  the 
organization,  were  also  realized. 

F.  METHODOLOGY 

The  goals  of  the  project  were  both  to  develop  an  actual  working  product  and  to 
design  a  prototype  that  demonstrates  the  capabilities  of  the  technology.  The  Waterfall 
Model  or  Systems  Development  Lifecycle  (SDLC),  with  its  process  of  clearly  defined 
steps,  was  used  to  develop  the  working  Intranet  product.  The  Waterfall  Model  approach 
was  helpful  in  structuring  the  development  progress  from  requirements  analysis  at  the 
start  until  final  implementation  at  the  ESU  by  the  end. 


3 


G.  INTRANET  DESIGN  AND  APPLICATION  FEATURES 


The  project  design  incorporates  two  partitions  labeled  “Intranet”  and  “Extranet”. 
“Intranet”  information  is  protected  by  security  access  levels  and  authorized  users  are 
specifically  limited  to  ESU  employees  use  only.  “Intranet”  information  includes  access 
to  personnel  and  supply  databases  and  the  ability  to  execute  Intranet  applications  that  take 
their  data  from  those  databases.  “Extranet”  information  is  available  to  anyone  who  is  on 
the  Coast  Guard  Data  Network  Web  (CGWEB).  The  CGWEB,  as  defined  in  USCG 
Commandant  Instruction  5230.57,  uses  Internet  technology  inside  the  USCG  security 
perimeter  (users  behind  USCG  firewalls)  to  provide  a  “private  Internet”.  ESU  “Extranet” 
information  includes  a  phone  and  e-mail  directory,  access  to  other  ESU  Alameda 
department  Web  sites,  and  the  daily  list  of  who  is  on  leave  or  away  for  temporary  duty. 

Security  is  implemented  on  a  page  by  page  basis.  When  a  page  is  requested,  the 
security  access  level  is  checked  and  access  is  granted  or  denied  based  on  the  access  level 
the  user  has  logged  in  at. 

On-line  form  processing  is  a  significant  application  feature  on  the  Intranet.  Forms 
that  were  once  filed  and  routed  through  office  inboxes  and  outboxes  can  now  be 
instantaneously  routed  through  virtual  inboxes  and  outboxes.  The  form  data  is 
automatically  stored  in  databases.  This  provides  new  ways  to  query  and  manipulate  data 
that  was  once  only  stored  in  filing  cabinets  or  not  at  all. 

The  site  design  is  generic  enough  to  be  installed  at  other  Coast  Guard  units.  Once 
ESU  Alameda  tests  the  Intranet  and  fine  tunes  it,  it  could  possibly  be  deployed  to  other 
local  commands,  to  other  ESU’s  or  any  other  Coast  Guard  units. 

The  Leave,  Temporary  Assigned  Duty  (TAD),  and  Recall  Log  are  three 
applications  that  support  the  ESU’s  priority  of  keeping  better  track  of  personnel.  The 
Marks  Application  supports  the  Command’s  goal  of  forecasting  when  personnel  marks 
are  due.  The  Supply  Application  introduces  on-line  form  processing  and  status  updates 
for  Purchase  Requests.  This  supports  the  ESU’s  interest  in  improving  the  supply 
ordering  processes.  The  Announcements  Application  facilitates  better  communications 
throughout  the  ESU.  The  Phonebook  Application  provides  “Extranet”  visitors  with  up- 
to-date  phone  numbers  and  email  addresses. 
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H.  INTRANET  IMPLEMENTATION 

The  Intranet  will  be  installed  at  the  ESU  during  the  summer  of  1998.  There  are 
many  issues  of  managing  social  and  technical  change  which  could  affect  the  complete 
adoption  of  a  new  tool  like  an  Intranet. 

In  order  for  the  ESU  to  take  ownership  for  and  maintain  their  new  Intranet  site, 
both  the  management  solutions  and  the  technical  solutions  must  be  addressed  during 
implementation.  From  the  business  perspective,  the  ESU  will  have  to  write  their  own 
policy  on  Intranet  use  to  include  guidance  on  security,  acceptable  use  instructions  and 
backups.  Recommendations  on  change  management,  or  how  to  introduce  a  new 
information  system  to  an  organization,  were  included  as  part  of  this  thesis.  Technical 
details  of  the  Intranet  were  included  in  this  thesis  as  well. 

I.  CONTENTS 

This  section  contains  a  brief  summary  of  the  thesis  chapters. 

1.  Chapter  I.  Background 

This  chapter  introduces  the  thesis  topic,  customer  and  a  brief  definition  and 
discussion  of  the  Intranet,  its  applications  and  implementation  issues. 

2.  Chapter  II.  Intranet 

This  chapter  introduces  terms  used  throughout  the  thesis.  Discussion  in  this 
chapter  focuses  on  what  an  Intranet  is,  how  it  can  affect  an  organization,  and  the  technical 
requirements  for  implementing  one. 

3.  Chapter  III.  Limitations  and  Assumptions 

This  chapter  describes  the  limitations  and  assumptions  that  affected  decisions 
about  what  Intranet  applications  were  actually  developed  for  the  ESU. 

4.  Chapter  IV.  Methodology 

The  Intranet  development  and  design  methodology  is  described  in  this  chapter. 
The  stages  of  the  Waterfall  Model  are  defined  here.  Discussion  of  how  each  stage  was 
conducted  is  presented  in  this  chapter.  The  Rapid  Prototyping  model  is  also  defined  here. 
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5.  Chapter  V.  Analysis 

Analysis  of  ESU  Alameda’s  business  model  is  covered  in  this  chapter.  The 
criteria  for  selection  of  business  processes  for  Intranet  solutions  are  described  here. 
These  criteria  drove  Intranet  development.  The  chapter  finishes  with  a  logical  design  of 
an  ESU  Intranet. 

6.  Chapter  VI.  Software  Tools 

This  chapter  identifies  what  software  tools  were  used  for  developing  the  Intranet. 
The  reasons  why  these  tools  were  chosen  are  explained  here. 

7.  Chapter  VII.  Physical  Design 

A  brief  tutorial  of  how  to  physically  build  an  Intranet  is  provided  in  this  chapter. 
The  guiding  principles,  such  as  the  Graphic  User  Interface,  behind  hundreds  of  hours  of 
code  and  development  effort  are  discussed  in  this  chapter. 

8.  Chapter  VIII.  The  Applications 

The  applications  are  the  final  products  from  the  physical  design  phase.  This 
chapter  details  each  specific  Intranet  application  and  how  it  is  meant  to  be  used.  Screen 
shots  of  each  relevant  Web  page  of  the  applications  are  included. 

9.  Chapter  IX.  Implementation 

This  chapter  covers  implementation  primarily  from  a  management  perspective. 
The  idea  that  it  is  the  social  aspect,  not  solely  the  technical,  that  determines  the  outcome 
of  an  information  systems  change  in  an  organization  is  discussed  in  this  chapter.  An 
organizational  change  formula  is  also  presented  here. 

10.  Chapter  X.  Conclusion 

This  chapter  contains  the  conclusion.  A  look  to  the  future  for  further  development 
ideas  and  lessons  learned  are  also  presented  here. 

11.  Appendix  A:  ASP  Application  Design  and  Code 

The  appendix  contains  a  short  explanation  of  how  Active  Server  Pages  were  used 
to  implement  the  Announcements  Application  on  the  Intranet.  The  on-line 
announcements  form  queries  the  user  for  information,  updates  the  database,  and  displays 
a  result.  These  interactions  are  typical  and  found  in  most  of  the  applications  across  the 
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Intranet.  The  HTML,  Visual  Basic  Script  and  ASP  code  listings  are  presented  in  both  a 
visual  context  as  well  as  textual. 

12.  Appendix  B:  Glossary  of  Terms 

This  glossary  is  reprinted  from  various  on-line  services.  It  provides  the  thesis 
reader  with  the  definitions  of  some  of  the  technical  terms  used  throughout  the  thesis. 

13.  Enclosures 

The  source  code  for  the  thesis  is  contained  on  a  CD-ROM  disk.  This  disk 
contains  a  folder  named  "prototype2"  with  all  the  Web  pages  of  the  Intranet  site.  This 
folder  may  be  copied  to  the  WWWROOT  directory  of  any  Windows  Internet  Information 
Server,  running  Active  Server  Pages,  for  an  instant  Intranet.  A  "ReadMe"  file  is  included 
to  address  the  specifics  of  installation.  The  disk  contains  three  Access  databases  named 
"phonebook",  "supply",  and  "announcements".  The  text  of  this  thesis  is  also  on  the  CD- 
ROM.  (Note  that  this  CD-ROM  is  not  included  with  all  copies  of  this  thesis.  It  can  be 
checked  out  from  the  Dudley  Knox  Library  at  NPS.) 
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II.  INTRANET 


A.  INTRODUCTION 

An  Intranet  opens  the  channels  of  communication  to  allow  sharing,  updating  and 
querying  for  information  throughout  the  network  without  regard  to  time  or  distance.  This 
chapter  briefly  defines  what  an  Intranet  is,  what  benefits  may  result  from  having  one,  and 
how  it  works.  Discussion  of  the  ESU  Intranet  is  also  included  here. 

B.  INTRANET  DEFINED 

An  Intranet  adapts  the  technologies  used  on  the  World  Wide  Web  for  use  on  an 
internal  network.  In  essence,  it  is  a  private  Internet.  An  Intranet  uses  a  client-server 
model.  This  means  it  is  run  from  a  central  Web  server  with  client  computers  accessing  it 
through  Web  browsers. 

The  reference  to  “ESU  Intranet”  throughout  the  thesis  primarily  refers  to  the 
actual  Web  pages  the  end-user  sees  in  their  Web  browser  window.  In  reality,  the  scope  of 
the  ESU  Intranet  is  broader  and  it  includes  all  the  underlying  components  and  code 
necessary  to  run  the  client-server  Intranet  site.  When  a  client  computer  makes  a  request 
on  the  Intranet,  these  components  allow  back-end  databases  to  feed  data  to  the  Web 
server.  The  Web  server  then  dynamically  generates  Web  pages,  from  the  results  of  the 
database  query,  and  outputs  the  pages  to  client  Web  browser  that  made  the  request. 

To  develop  and  maintain  an  Intranet,  the  minimum  requirements  include  a 
Transmission  Control  Protocol/Intemet  Protocol  Local  Area  Network  (TCP/IP  LAN),  a 
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Web  server,  Web  browsers,  and  Web  authoring  tools.  Intranet  information  is  typically 
displayed  on  Web  pages  in  a  client  terminal’s  Web  browser  window. 


C.  INTRANET  BENEFITS 


There  are  numerous  benefits  to  an  Intranet.  The  essence  of  it  is  that  more 

information  is  available  to  more  people  in  a  common,  accessible  format.  An  Intranet  is 

“...  a  TCP/IP  network  inside  a  company  that  links  the  people  and 
information  in  a  way  that  makes  people  more  productive,  information 
more  accessible,  and  navigation  through  all  the  resources  and  applications 
more  seamless  than  ever  before.”  (p.57,  Burleson,  1994) 


the  Benefits 


-  distributed  access  to 
wide  range  of  infomtation 
and  services 


-  increased  platform  independence 

•  enterprise  information  sharing 

•  irtfomialion  provided  in  context 
■  historical/overtime  sharing 

w 

•  easier  interaction  with  experts 
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Figure  2.1  Intranet  Benefits  and  Challenges  (CIO  Insider) 

These  common  applications  usually  are  the  first  to  be  implemented  on  a  new 
Intranet.  Initially,  they  tend  to  demonstrate  the  capabilities  of  the  new  technology  and 
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often  have  an  immediate  and  dramatic  impact  on  the  organization.  The  applications 
include: 

•  phone  directories 

•  employee  information 

•  company  policies 

•  product  information 

•  training  information 
Other  powerful  applications  include: 

•  database  interactions 

•  groupware 

•  knowledge  capture 

•  decision  support 

Remote  access  to  the  Intranet  is  possible  through  a  common,  platform 
independent,  interface.  Platform  independence  means  that  even  clients  running  different 
operating  systems  on  different  kinds  of  computers  can  access  the  Intranet.  For  example, 
an  Intranet  that  is  hosted  on  an  Intel  Pentium-based  computer  running  Microsoft  NT 
Internet  Information  Server  can  be  accessed  by  Sun  Solaris  UNIX-based  computers  or 
even  Macintosh  clients.  Any  computer  capable  of  running  a  Web  browser,  that  has  a 
connection  to  the  Intranet  network,  can  access  the  Intranet  and  its  Web  enabled  databases. 
The  Web  browser  takes  the  place  of  a  traditional  application  specific  interface. 
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These  and  other  Web-enabled  applications  have  the  power  to  change  an  entire 
organizational  environment  by  “making  information,  once  buried  in  hundreds  of  places  in 
the  organization,  available  to  everyone”  (pp.  15-16,  Burleson,  1994). 

D.  INTRANET  SCOPE 

An  Intranet’s  scalability  is  virtually  unlimited  since  it  uses  the  same  technologies 
that  make  the  global  World  Wide  Web  possible.  One  of  the  most  powerful  features  of  an 
Intranet  is  access  to  enterprise-wide  information  without  regard  to  time  or  distance.  The 
term  “enterprise”  means  the  entire  organization.  For  example,  the  Ford  Motor  Company 
Intranet  could  provide  employee  benefits  information  to  all  of  its  employees  worldwide 
through  an  enterprise  wide  Intranet. 

The  U.S.  Coast  Guard  is  the  enterprise  with  regard  to  the  ESU  Alameda  Intranet. 
The  USCG  enterprise  wide  Intranet  is  currently  under  construction  on  the  Coast  Guard 
Data  Network  Web  (CGWEB).  The  CGWEB,  as  defined  in  USCG  Commandant 
Instruction  5230.57,  uses  Internet  technology  inside  the  USCG  security  perimeter  (users 
behind  USCG  firewalls)  to  provide  a  “private  Internet”. 

Any  USCG  employee  who  has  access  to  the  CGWEB  will  be  able  to  access  the 
ESU  Alameda  Intranet.  This  gives  the  ESU  the  power  to  update  its  own  information, 
such  as  its  phone  directory,  and  the  change  is  immediately  reflected  and  available 
throughout  the  enterprise. 

Not  all  Intranet  information  is  appropriate  for  enterprise  wide  distribution. 
Payroll  or  financial  data,  for  example,  should  not  be  distributed  as  widely  as  phone 
directory  information.  An  Intranet  typically  will  have  internal  and  external  customers. 


12 


The  ESU  Intranet  is  modeled  with  two  distinct  Intranet  areas.  Information  posted  on  the 
ESU  “Extranet”  is  available  enterprise  wide  to  anyone  with  access  to  the  CGWEB.  The 
ESU  “Intranet”  data  is  only  available  to  ESU  employees  and  access  requires  a  login  and 
password  check. 

E.  HOW  INTRANETS  WORK 

1.  Client-Server  Model 

The  client-server  model  is  very  simple.  One  computer  on  a  network,  the  server, 
acts  as  a  central  processor  for  a  group  of  client  computers.  The  server  is  dedicated  to 
responding  to  requests  from  client  computers.  For  example,  an  application  server  would 
host  a  shared  application,  such  as  a  word  processing  program,  which  could  then  be 
executed  on  any  client  computer  on  the  network. 


Cl  lent-Serve r  Model 


Figure  2.2  Client-Server  Model 

A  Web  browser  and  Web  server  emulate  the  client-server  information  systems 
model.  The  Web  server  on  the  ESU  Intranet  responds  to  requests  from  clients  by 
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querying  its  databases  and  then  dynamically  generating  Web  page  code.  The  Web  server 
returns  the  code  to  the  client’s  Web  browser  window. 

The  ESU  Intranet  client-server  models  work  with  a  middleware  component  that 
facilitates  the  interaction  of  the  databases  with  the  Web  browser.  The  Web  server  hosts 
the  Intranet  site  by  generating  and  serving  HTML  code  to  the  client  Web  browsers  upon 
request.  The  database  holds  all  the  relevant  data  for  Intranet  applications. 

2.  Network 

The  ability  to  have  an  Intranet  depends  on  having  computers  that  can 
communicate  with  each  other.  If  two  computers  want  to  exchange  data,  they  must  speak 
the  same  language.  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP)  is  the 
protocol,  or  common  network  language,  that  allows  computers  to  exchange  data.  There 
are  other  protocols  available,  but  TCP/IP  is  the  one  used  to  transmit  data  across  the 
Internet.  It  is  such  a  versatile  language  that  data  can  be  sent  from  one  computer,  routed 
over  the  Internet,  and  arrives  across  the  globe  just  as  it  was  sent. 

3.  Static  and  Dynamic  Web  Pages 

Typical  Web  pages  are  static  documents,  which  means  that  they  do  not  change. 
Static  pages  are  written  once  and  served  to  the  client’s  Web  browser  in  Hypertext  Markup 
Language  (HTML)  code.  For  example,  a  Web  page  that  contains  the  text  of  the 
Constitution  of  the  United  States  would  be  static  because  the  HTML  code  could  be 
written  once  and  then  never  (or  rarely)  need  to  be  changed. 
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Most  of  the  Web  pages  on  the  ESU  Intranet  are  different  because  the  pages  are 
dynamic.  The  HTML  code  for  a  dynamic  Web  page  is  individually  recreated  on  the  Web 
server  every  time  a  client  browser  requests  a  page.  This  is  called  “server  side  scripting” 
because  the  server  rewrites  every  HTML  page  at  the  server  before  passing  it  to  the  client. 
For  example,  a  Web  page  that  displays  the  results  of  an  Web  search  on  the  keyword 
“constitution”  would  be  dynamic  because  the  Web  server  would  have  to  generate  a  new 
and  unique  response,  in  HTML  for  the  client,  specifically  on  that  keyword  search. 

F.  INTRANET  APPLICATIONS 

1.  Web  browser  as  Application  Interface 

The  traditional  view  of  an  application  is  that  it  is  a  standalone  program  that  is 
launched  with  its  own  uniquely  developed  human  to  computer  interface.  With  a  Web 
enabled  Intranet  application,  the  user  can  navigate  through  an  application  with  a 
customized  interface  created  for  the  Web  browser.  While  there  are  certainly  limitations 
with  what  one  can  accomplish  visually  in  a  Web  browser  window,  there  is  a  huge  benefit 
in  that  every  single  Web-enabled  application  can  be  launched  through  the  same  human  to 
computer  interface  window. 

For  example,  in  a  traditional  Microsoft  Access  database  application,  the  user 
navigates  the  database  through  either  the  default  Access  interface  or  a  customized 
interface  created  by  the  developer  from  within  Access.  Either  way,  the  user  is  still 
running  the  database  through  the  Access  application  program.  The  Intranet  view  of  the 
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application  is  always  through  the  Web  browser.  In  fact,  on  the  Intranet  the  Access 
application  program  is  never  launched  or  even  seen  by  the  user. 

2.  Other  TCP/IP  Applications 

Applications  and  other  protocols  “ride”  on  top  of  TCP/IP.  Although  the  Web 
browser,  which  uses  the  HyperText  Transport  Protocol  (HTTP),  is  the  most  common 
Intranet  application,  any  program  that  can  use  TCP/IP  can  be  implemented  across  an 
Intranet  network.  Other  useful  applications  include  e-mail  and  video  teleconferencing. 

3.  ESU  Intranet  Applications 

Applications  on  the  ESU  Intranet  are  defined  as  groups  of  interrelated,  dynamic 
Web  pages  that  interact  with  a  back-end  database.  The  Web  browser  window  is  the 
standard  interface  for  all  ESU  Intranet  applications. 

G.  CONCLUSION 

An  Intranet  is  a  powerful  tool  that  is  reshaping  the  way  people  communicate 
throughout  the  enterprise.  It  has  tangible  benefits,  it  is  fairly  easy  to  deploy,  and  just  as 
the  Internet’s  growth  is  seemingly  unlimited,  an  Intranet’s  scalability  is  virtually 
unrestricted.  There  are  also  countless  challenges,  such  as  maintaining  current  content, 
and  consequences,  such  as  changing  existing  business  processes,  of  using  this  new 
technology. 

The  rest  of  this  thesis  will  explore  these  challenges  and  consequences  of  turning 
the  idea  of  an  Intranet  into  a  reality  for  a  mid-sized  USCG  unit.  Designing  the  product. 
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aligning  the  technology  with  the  unit’s  business  goals,  and  successfully  introducing 
change  will  be  covered. 
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III.  LIMITATIONS  AND  ASSUMPTIONS 


A.  INTRODUCTION 

The  author  faced  limitations  of  competency  and  technical  skill  and  made 
assumptions  for  this  project.  Choices,  which  affected  the  ultimate  design  of  the  system, 
were  governed,  in  part,  by  these  factors  so  discussion  of  them  is  warranted. 

B.  INTRANET  DEVELOPMENT  ASSUMPTIONS 

1.  Introduction 

The  focus  of  this  thesis  is  on  the  complete  process  of  Intranet  systems 
development.  This  thesis  concludes  with  an  actual  physical  product  that  is  ready  for 
operational  testing  and  daily  use. 

2.  Qualifications 

The  scope  of  thesis  had  to  be  narrowed  to  a  practical  and  attainable  goal.  This 
means  that  choices  had  to  be  made  about  which  processes  would  be  modeled  and  what 
priority  they  would  take.  The  abilities  of  the  author  were  a  significant  factor  in  which 
choices  were  made  for  the  final  product.  For  that  reason,  some  discussion  of  what  those 
abilities  are  and  how  they  were  acquired  is  relevant. 

Qualifications  to  undertake  this  project  were  acquired  over  eighteen  months  of 
classroom  instruction  and  self-study  in  the  Naval  Postgraduate  School’s  Information 
Technology  Management  curriculum.  The  curriculum  covers  many  methodologies  and 
theories  of  the  logical  process  of  information  systems  analysis,  design,  development  and 
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implementation.  The  management  aspects  of  introducing  information  system  change  to 
an  organization  are  also  covered  in  this  curriculum. 

The  technical  aspects  of  developing  code  and  choosing  appropriate  software  tools 
for  the  physical  design  of  the  Intranet  were  mainly  learned  through  self-study.  The  tools 
and  applications  that  were  learned  during  the  four-month  development  phase  included 
various  Web  site  design  tools,  database  applications,  Internet  servers,  middleware,  Visual 
Basic  script  and  JavaScript  programming  languages.  A  method  for  learning  these  tools 
included  consulting  many  books,  tutorials,  on-line  guides,  trade  journals,  Internet 
resources  and  resorting  to  serendipitous  trial  and  error.  A  proficiency,  but  not  expertise, 
in  all  of  the  critical  areas  was  attained. 

3.  Coast  Guard  Perspective 

Being  a  United  States  Coast  Guard  officer,  the  author  had  relevant  experience, 
which  provided  a  foundation  for  analyzing  the  needs  and  processes  of  a  USCG  unit.  This 
USCG  background  had  natural  advantages  for  requirements  analysis.  It  also  led  to  some 
assumptions  of  how  a  USCG  unit  should  look.  A  USCG  consultant  working  for  a  USCG 
customer  does  face  the  danger  of  simply  automating  existing  business  processes  instead 
of  re-thinking  them  in  fresh  new  ways.  The  author  was  conscious  of  this  possible  bias. 

4.  Remote  Development  Site 

Although  there  was  a  comprehensive  analysis  of  the  ESU’s  business  model,  the 
Intranet  developer  will  not  use  the  ESU  Intranet  on  a  day  to  day  basis.  The  Intranet  was 
not  created  on  site  in  the  true  ESU  Alameda  working  environment.  Instead,  it  was 
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developed  remotely  at  Naval  Postgraduate  School.  This  offered  the  advantage  of  a  fresh 
perspective.  There  is,  however,  a  danger  that  some  aspects  of  the  ESU  business  model 
were  missed  which  may  affect  the  chances  of  long  term  Intranet  success. 

5.  Resource  Constraints 

Naval  Postgraduate  School,  not  the  thesis  customer,  provided  almost  all  of  the 
resources  necessary  to  complete  the  project.  These  resources  included  access  to  a 
Windows  NT  server  class  computer,  a  dedicated  Internet  Protocol  address  registered  with 
the  InterNic  Domain  Name  Service  as  “cg.nps.navy.mil”,  and  various  software 
development  tools. 

Money  played  a  role  in  the  selection  of  software  development  tools.  The  sponsor 
had  limited  funds  and  only  agreed  to  pay  for  a  few  days  of  thesis  travel  and  one  technical 
book.  The  sponsor  purchased  one  $50  software  component  which  was  required,  but  was 
unwilling  to  spend  a  significant  amount  of  money  for  new,  non-Coast  Guard  standard 
software  for  a  research  project.  A  primary  criterion  for  selection  of  software  tools  was 
therefore  price  and  academic  availability. 

Since  the  science  of  and  tools  for  Intranet  development  are  relatively  new,  there 
are  few  books  and  references  in  the  NPS  library.  Most  of  the  books  and  relevant 
reference  material  had  to  be  purchased  or  looked  up  on-line  over  the  Internet.  Technical 
books  on  Intranets  and  software  generally  cost  $60  to  $100.  Aside  from  the  one  technical 
book  the  customer  purchased,  all  other  relevant  technical  books  were  borrowed  from  NPS 
or  purchased  individually.  This  constraint  meant  the  developer  was  highly  selective  in 
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which  tools  to  attempt  to  learn.  Buying  the  books  to  learn  too  many  different  software 
tools  was  prohibitively  expensive. 

6.  Assumptions 

Assumptions  made  for  this  project  affected  the  development  and  outcome  of  it  in 
various  degrees.  A  brief  list  of  these  assumptions  follows. 

The  biggest  assumption  was  that  ESU  Alameda  actually  wanted  a  new  Intranet 
developed  as  part  of  an  NPS  thesis.  The  Intranet  idea  was  proposed  from  the  author  to 
the  customer,  not  the  other  way  around.  Also,  it  was  assumed  that  the  thesis  would  not  be 
funded  to  the  degree  of  other  projects  whose  sponsors  have  specific  research  goals  or 
agendas.  Since  the  Intranet  proposal  did  not  come  from  within  the  ESU,  it  was  assumed 
that  some  employees  of  the  unit  would  resist  the  change  the  new  Intranet  introduces. 

A  belief  that  Intranet  technologies  could  improve,  enhance  or  re-engineer  existing 
aspects  of  the  ESU  Alameda  business  model  was  also  presupposed.  Finally,  it  was 
assumed  that  the  project  was  feasible.  There  was  a  faith  that  acquiring  the  technical  skills 
and  qualifications  to  see  the  project  through  to  completion  was  possible. 

7.  Technical  Ability  Bias 

The  lack  of  a  comprehensive  technical  expertise  may  have  introduced  bias  into  the 
selection  of  business  process  Intranet  applications  to  develop  and  the  software  tools  to 
design  with.  Inexperience  may  have  prevented  an  entirely  critical  evaluation  of  the 
variety  of  Intranet  software  development  tools  available.  A  bias  towards  picking 
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software  tools  that  were  the  easiest  to  use  and  learn,  and  a  tendency  to  choosing  the  least 
complex  business  processes  for  application  design,  occurred  in  this  project. 

8.  Time  Constraint 

Ideally,  the  author  would  have  liked  to  create  a  more  comprehensive  Intranet  site 
for  the  customer.  The  site  would  contain  more  applications  for  more  Web  enabled 
business  processes.  There  would  be  rich  content  organized  by  knowledge  area,  more 
decision  support  tools  would  be  available  and  easy  content  development  applications 
would  be  used  on  the  Intranet  to  empower  all  members  of  the  organization  to 
communicate  in  new  ways.  In  reality,  the  most  significant  constraint  that  stood  in  the 
way  of  such  a  comprehensive  effort  was  that  there  simply  was  not  enough  time. 

C.  CONCLUSION 

Despite  these  biases,  constraints,  and  assumptions,  the  final  product  works  and 
meets  many  of  the  ESU’s  goals  and  needs.  This  Intranet  may  yet  be  the  seed  of  a  new 
USCG  information  system,  which  could  grow  into  a  much  larger  implementation,  as  the 
customer  discovers  its  power  and  utility. 
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IV.  METHODOLOGY 


A.  INTRODUCTION 

A  methodology  is  a  “comprehensive,  multi-step  approach  to  systems 
development”  (p.8,  Hoffer,  George,  Valacich,  1996).  The  development  methodology  of 
the  ESU  Intranet  project  was  the  Waterfall  Model.  Aspects  of  the  Rapid  Prototyping 
approach  were  also  used  to  physically  design  the  product. 

The  Waterfall  Model,  otherwise  known  as  the  Systems  Development  Lifecycle 
(SDLC),  is  a  relatively  formal  process  of  clearly  defined  steps,  which  occur  discretely  one 
after  another.  The  Waterfall  Model  is  typically  used  to  develop  large-scale  information 
systems. 

Rapid  Prototyping  sometimes  referred  to  as  Rapid  Application  Design  (RAD),  is  a 
much  less  formal  method  of  iterative  development.  RAD  is  intended  to  quickly  develop  a 
prototype  that  can  either  become  immediately  operational  or  redesigned  later  using  a 
more  comprehensive  formal  approach. 

The  first  goal  of  this  project  was  to  develop  an  actual  working  Intranet  product. 
The  Waterfall  Model  was  used  as  the  complete  lifecycle  model  for  development  from 
beginning  to  end.  The  Waterfall  Model  provides  a  comprehensive  framework  for 
information  systems  development  from  requirements  analysis  at  the  outset  until  a  final 
implementation  by  the  close. 

A  second  goal  of  the  project  was  to  develop  a  prototype  that  demonstrates  the 
capabilities  of  the  technology.  The  final  product  can  actually  be  regarded  as  one  phase  of 
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a  Rapid  Prototype  iterative  design  loop.  From  this  perspective,  the  Intranet  is  never 
really  completed.  Following  the  initial  installation,  it  is  continuously  improved  and 
refined  locally  by  the  client. 


B.  WATERFALL  MODEL  DEFINED 


The  Waterfall  Model  is  a  multi-stage,  comprehensive  methodology  with  seven 
clearly  defined  steps.  The  approach  uses  a  formal  process  to  systems  design  that  reduces 
the  probability  of  bugs  in  the  design.  With  its  emphasis  on  proper  requirements  analysis 
at  the  beginning  and  on  proper  implementation  and  maintenance  at  the  end,  it  widens  the 
development  perspective  to  include  more  than  just  a  focus  on  writing  computer  code. 


The  seven  stages,  as  described  in  the  textbook  Modem  Systems  Analysis  and 


(p.24,  Hoffer,  George,  Valacich,  1996),  are  presented  below. 


Figure  4.1  Waterfall  Model  of  the  Systems  Development  Lifecycle 


The  Waterfall  Model  is  an  excellent  choice  for  a  structured  development  effort 
conducted  in  discrete  phases.  The  project  is  scheduled  with  timelines  and  critical 
milestones.  It  is  a  very  good  method  for  developing  systems  to  meet  well  defined, 
mathematical  requirements.  The  customer  tends  to  prefer  this  methodology  as  the 
progress  of  the  development  effort  is  well  documented  and  scheduled  in  phases. 

There  are  disadvantages  of  the  model.  It  is  difficult  to  use  when  a  customer 
cannot  clearly  and  specifically  articulate  system  requirements.  Documentation  and 
analysis  using  Data  Flow  Diagrams  (DFD),  Entity-Relationship  Diagrams  and  other 
Computer  Aided  System  Engineering  (CASE)  tools  can  lead  to  a  never  ending  cycle  of 
analysis,  or  “analysis  paralysis”.  There  is  very  little  room  for  risk  analysis  as  the  project 
progresses  on  its  schedule. 

Although  not  all  aspects  of  the  Waterfall  Model  were  entirely  appropriate  for  the 
ESU  Intranet  development,  it  did  provide  a  structured  methodology  to  follow.  The 
chapters  of  this  thesis,  and  the  development  aspects  they  cover,  are  related  to  each  phase 
of  development  under  the  Waterfall  Model.  The  seven  development  stages  of  the 
Waterfall  Model,  with  the  thesis  chapters  that  correspond  to  a  particular  development 
stage,  are  presented  in  Figure  4.2. 
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1.  Project  Identification  and  Selection 

Chapters  II,  III,  IV 

2.  Project  Planning 

Chapters  II,  III,  IV 

3.  Analysis 

Chapter  V 

4.  Logical  Design 

Chapter  V 

5.  Physical  Design 

Chapters  VI,  VII,  VIII 

6.  Implementation 

Chapter  IX 

7.  Maintenance 

Chapter  IX 

Figure  4.2  Stages  of  Waterfall  Model  and  Thesis  Chapters 


C.  WATERFALL  MODEL  APPLIED 


1.  Project  Identification  and  Selection 

The  first  phase  of  the  waterfall  is  project  identification  and  selection.  During  this 
phase,  a  range  of  projects  and  ideas  is  considered  and  a  general  conceptual  project  idea  is 
selected  (p.24,  Hoffer,  George,  Valacich,  1996).  Selection  is  based  on  various  factors 
such  as  feasibility,  cost  versus  benefit,  the  readiness  of  the  organization  and  the 
capabilities  of  the  development  team. 

For  this  thesis,  several  potential  USCG  test  environments  were  considered.  These 
included  an  Intranet  for  a  USCG  cutter,  for  a  small  boat  station,  or  for  an  office 
environment.  Electronic  Support  Alameda  was  the  final  choice. 

ESU  Alameda  was  selected  as  the  thesis  sponsor  primarily  because  it  is  an 
innovative  Command  which  is  on  the  cutting  edge  of  the  Coast  Guard  information 
technology  changes.  The  ESU’s  Commanding  Officer  officially  states  in  ESU  Alameda 
Standard  Operating  Procedures  Instruction  5400. IB  that  he  expects  each  employee  “to 
improve  our  system  of  doing  business,  to  be  innovative”  (p.l,  Lane,  1996). 
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ESU  Alameda  was  especially  receptive  to  the  idea  of  sponsoring  a  prototype 
Intranet  development  effort.  Unlike  most  Coast  Guard  units  who  have  older,  non- 
Windows  based  computers,  ESU  Alameda  already  had  the  hardware  and  software 
requirements  necessary  for  a  Microsoft  Windows  based  Intranet.  Specifically,  they  had 
networked  IBM-compatible  computers  running  Microsoft  Windows  NT  Server  and 
Workstation  operating  systems. 

2.  Project  Initiation  and  Planning 

During  the  project  initiation  and  planning  phase,  the  general  information  systems 
concept  begins  to  take  shape.  The  project  is  initiated  when  the  customer  is  contacted. 
The  feasibility  of  the  project,  the  costs  and  benefits  of  it,  the  scope,  and  objective  are  all 
considered.  For  large  scale  systems  development  using  the  Waterfall  Model,  a  formal 
report  would  generally  be  written  after  this  stage  which  would  cover  all  of  these  issues  at 
length,  (p.25,  Hoffer,  George,  Valacich,  1996). 

For  this  project,  the  process  was  much  less  formal.  ESU  Alameda  was  contacted 
and  the  Intranet  idea  proposed.  The  ESU  Command  welcomed  the  development  effort 
and  pledged  its  support.  A  cursory  analysis  of  the  current  state  of  the  ESU’s  information 
systems  was  done  via  telephone  and  the  project  was  determined  to  be  feasible.  The  ESU 
made  money  available  for  travel  to  Alameda  in  order  to  conduct  the  business  analysis  and 
agree  on  requirements. 
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3.  Analysis 


The  Analysis  phase  is  one  of  the  most  important  steps  to  information  systems 
design.  It  is  when  the  client’s  business  model  is  examined  in  detail.  The  design  team 
must  thoroughly  understand  current  business  processes  and  select  candidate  processes  for 
Intranet  development.  The  customer’s  requirements  for  a  successful  system  are 
determined.  The  flow  of  information,  data  and  business  processes  are  exhaustively 
explored  and  diagrammed,  (p.25,  Hoffer,  George,  Valacich,  1996) 

The  business  model  analysis  was  conducted  over  a  two  day  visit  to  the  ESU. 
Interviews  were  conducted,  meetings  were  facilitated,  and  documents  researched  in  order 
to  reach  a  clear  understanding  of  the  ESU’s  mission,  their  business  model,  and  their  way 
of  doing  business.  Requirements  analysis  revealed  the  top  goals  and  problems  the  ESU 
faced. 

Following  the  business  analysis,  it  was  possible  to  narrow  the  scope  of  the  project 
to  focus  on  the  Command’s  top  priorities.  These  three  top  priorities  were  found  to  be: 

•  keeping  better  track  of  personnel  movements  and  administration 

•  improving  the  supply  ordering  and  procurement  process 

•  status  monitoring  of  Casualty  Report  (CASREP)  service  requests 
The  business  analysis  is  thoroughly  explored  in  Chapter  V. 

4.  Logical  Design 

The  logical  design  phase  is  when  the  components  of  the  information  system  are 
defined  without  regard  to  any  specific  hardware  or  software  platform.  The  functional 
goals  of  the  system  are  visualized  without  consideration  of  the  physical  implementation. 


30 


The  logical  design  phase  focuses  on  business  processes  and  conceptual  system  solutions 
for  them.  By  the  end  of  this  phase  developers  should  have  a  clear  idea  of  what  they  want 
their  system  design  to  do.  (p.25,  Hoffer,  George,  Valacich,  1996) 

A  functional  decomposition  diagram  (see  Figure  5.9),  which  is  the  logical 
blueprint  for  the  Intranet,  was  the  main  product  for  this  phase  of  development.  The 
diagram  included  all  the  system  design  goals  without  regard  to  actual  physical  design, 
software  tools  or  hardware  platform. 

5.  Physical  Design 

In  this  phase,  the  logical  design  is  converted  into  an  actual  physical 
implementation.  The  process  of  turning  the  concept  into  a  reality  includes  deciding  what 
software  tools  to  use,  what  platform  to  develop  on,  what  language  to  code  with.  Chapter 
VI  describes  in  detail  why  certain  software  tools  were  selected  for  developing  the  ESU 
Intranet.  Chapter  VII  details  the  necessary  steps  to  building  the  product. 

It  is  impossible  to  express  the  tremendous  amount  of  effort  it  took  to  learn,  plan, 
write  and  document  bug-free  code  to  make  the  Intranet  engine  turn.  Fortunately,  it  was 
possible  to  reduce  the  complexity  by  following  the  logical  blueprint  of  a  functionally 
decomposed  system.  Functionally  decomposed  means  the  Intranet  was  modular  and 
broken  down  into  parts.  Individual  parts  and  applications  could  be  separately  developed 
in  discrete  modules. 

The  interactions  between  modules  of  the  system  are  complex  enough,  however, 
that  good  documentation  of  the  code  was  absolutely  critical  to  success.  Considerable 
effort  went  into  ensuring  that  descriptive  documentation  accompanied  all  code. 
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6.  Implementation 


Implementation  includes  all  aspects  of  introducing  the  new  information  system 
into  the  organization.  This  includes  installation,  testing,  and  support  (p.26,  Hoffer, 
George,  Valacich,  1996).  The  implementation  phase  is  more  than  the  technical  aspects  of 
physical  installation  and  software  loading.  The  social  aspects  of  introducing  an 
information  systems  change  into  an  organization  must  also  be  considered.  It  is  the  social 
aspect,  far  more  than  the  technical,  which  will  ultimately  determine  the  outcome  of  the 
implementation. 

Managerial  obstacles  to  a  successful  implementation  of  the  Intranet  are  abundant. 
Any  change  that  redefines  the  lines  of  communication  in  a  system  is  likely  to  meet  with 
resistance  from  employees  who  may  prefer  old,  established  patterns.  These  and  other 
social  change  issues  are  explored  in  Chapter  IX. 

7.  Maintenance 

The  final  phase  of  the  Waterfall  Model  is  maintenance.  Most  of  the  lifecycle 
costs  associated  with  a  new  information  system  occur  during  the  maintenance  phase. 
(p.26,  Hoffer,  George,  Valacich,  1996)  In  many  instances,  the  system  designers  are  long 
gone  when  real  problems  occur.  For  this  reason,  it  is  incumbent  upon  the  developer  to 
provide  the  client  with  good  documentation,  training  and  a  method  for  system  change 
requests. 

The  ESU  Intranet  was  designed  with  maintenance  in  mind.  The  code  is 
painstakingly  documented  to  allow  for  a  higher  degree  of  maintainability.  A  separate 
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"Help"  Web  site  was  included  on  the  Intranet  to  provide  information  regarding 
maintenance,  support,  and  systems  feedback. 

D.  RAPID  PROTOTYPE  METHOD 

Many  customers  don’t  know  what  to  ask  for  or  how  to  describe  their  information 
system  needs.  Showing  them  an  example,  or  prototype,  is  a  very  effective  method  for 
allowing  customers  to  clarify  their  requirements.  The  prototype  can  demonstrate 
capabilities  of  a  technology  that  the  customer  did  not  even  know  existed.  It  provides  a 
good  starting  point,  which  may  then  be  adapted  to  the  individual  customer  needs.  The 
final  result  of  this  thesis,  the  ESU  Intranet,  is  essentially  a  prototype. 

Rapid  Prototyping  is  a  series  of  iterative  loops  of  development,  testing,  feedback, 
and  then  development  again  (p.28,  Hoffer,  George,  Valacich,  1996).  Customer 
requirements  are  initially  highly  abstract,  meaning  they  are  fuzzy  and  unclear.  The 
iterative  loops  of  the  Rapid  Prototype  method  clarify  the  system  requirements  until, 
eventually,  a  working  model  takes  shape.  The  prototype  may  then  be  used  as  a  functional 
system  or  as  a  model  for  a  larger  development  effort. 
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Figure  4.3  Iterative  Development  using  the  Rapid  Prototyping  Process 

The  Rapid  Prototype  method  has  advantages.  It  is  ideal  for  a  small, 
uncomplicated  project.  Development  can  begin  before  final  approval  of  funds  becomes 
available.  Various  modules  and  portions  of  the  project  can  be  developed  without  having 
to  stick  to  a  schedule  or  await  critical  milestones. 

The  method  also  has  dangers.  Unlike  the  Waterfall  Model,  which  proceeds 
sequentially  through  seven  well-defined  steps  including  a  physical  design  phase,  the 
Rapid  Prototype  is  always  in  the  physical  design  phase.  Since  the  requirements  for  the 
system  are  continually  refined  or  changed  throughout  the  development,  the  final  product 
may  turn  into  a  “build  and  fix”  solution.  The  resulting  system  code  might  not  flow 
consistently  and  it  is  likely  that  it  will  be  patchy  and  disorderly.  This  kind  of  tangled 
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“spaghetti  code”  can  be  difficult  to  maintain  or  understand.  By  contrast,  a  system 
developed  using  the  Waterfall  Model  should  have  reasonably  consistent  code  because  all 
the  requirements  and  specifications  have  been  defined  and  logically  modeled  prior  to 
physical  design.  The  cost  of  a  system  developed  by  the  informal  Rapid  Prototype  model 
may  be  greater  than  the  Waterfall  Model  in  the  long  run. 

E.  CONCLUSION 

This  chapter  defined  two  methodologies  for  systems  development  that  were 
relevant  to  this  thesis.  The  thesis  progressed  through  each  sequential  phase  of  the 
Waterfall  Model  because  it  provided  a  baseline  plan  for  the  entire  development  effort. 
The  result  of  the  development  under  the  Waterfall  Model  was  a  prototype  ESU  Intranet. 

The  Rapid  Prototype  model  is  relevant  because  the  final  result  of  the  thesis,  an 
ESU  Intranet,  can  be  regarded  as  simply  one  iteration  of  the  model.  The  implementation 
process  at  ESU  Alameda  will  determine  if  the  final  outcome  falls  to  the  left  (first 
prototype),  middle  (revised  prototype),  or  right  (final  prototype)  in  Figure  4.3.  In  any 
case,  the  ideal  goal  of  the  thesis  was  to  provide  the  ESU  with  a  “vision  of  what  is 
possible”  with  Intranet  technologies.  If  the  prototype  is  adopted  as  a  functional, 
operational  system  that  is  constantly  revised  and  enhanced,  as  shown  in  Figure  4.3,  then 
the  goal  will  have  been  far  surpassed.  (See  Chapter  IX  for  more  discussion  on 
implementation  issues.) 
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V.  ANALYSIS 


A.  INTRODUCTION 

The  analysis  phase  focuses  on  the  business  model  and  processes  of  the  client.  A 
systems  perspective  was  adopted  to  analyze  the  ESU  business  model.  Instead  of  simply 
focusing  on  discrete  linear  processes,  the  potential  benefits  and  consequences  of  Intranet 
technologies  for  the  entire  organizational  system  were  considered.  The  idea  that  one 
should  not  simply  automate  existing  paper  processes  was  a  guiding  principle  during  the 
analysis  phase.  The  goal  was  to  obliterate,  or  re-define,  old  processes  with  the  power  of 
new  Intranet  technology. 

This  chapter  will  explore  the  business  analysis  and  how  it  was  conducted  at  ESU 
Alameda.  The  most  important  findings,  specifically  the  identification  of  the  ESU’s  top 
priorities,  are  presented.  These  top  goals  drove  the  Intranet  development  and  narrowed 
the  field  of  candidate  processes  to  be  modeled  for  Intranet  applications.  A  logical,  or 
conceptual,  model  was  derived  from  the  business  analysis  results.  The  logical  model  is 
presented  here. 

B.  PROCESS  ANALYSIS  METHOD 

1.  Systems  Perspective 

The  Fifth  Discipline,  by  Peter  Senge,  advocates  a  systems  approach  to  thinking 
about  organizations,  which  provided  the  basis  for  exploration  of  the  ESU  business  model. 
Systems  thinking  involves  seeing  the  organization  as  whole  system  of  circular 
interdependencies.  The  opposite  of  systems  thinking  would  be  to  view  the  organization 
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as  being  broken  up  into  unrelated,  independent,  linear  processes.  Systems  thinking  is 
about  “seeing  processes  of  change  rather  than  snapshots”  and  “seeing  interrelationships 
rather  than  linear  cause-effect  chains”,  (p.73,  Senge,  1990) 

Simply  automating  existing  paper  trails  with  new  Intranet  technology  would  be 
like  taking  a  “snapshot”  of  the  process.  Instead  of  approaching  business  processes  one  at 
a  time,  the  research  focused  on  business  areas.  The  goal  was  to  find  ways  of  altering, 
enhancing  or  eliminating  processes  in  ways  that  would  benefit  the  entire  organizational 
system,  not  just  a  single  person.  With  its  ability  to  improve  communications  across 
organizational  boundaries,  an  Intranet  is  an  ideal  tool  to  approach  from  a  systems 
thinking  perspective. 

2.  Method 

The  field  research  consisted  of  two  days  of  exhaustive  interviews,  meetings  and 
documentation  reviews.  The  original  interview  plan  was  to  identify  business  processes, 
and  match  factors,  such  as  how  many  people  a  process  affects,  against  certain  criteria. 
Correlation  of  these  factors  with  these  criteria  was  designed  to  indicate  a  process' 
suitability  for  an  Intranet  solution.  The  plan  had  to  be  modified  mid-way  through  the  site 
visit,  as  it  became  apparent  that  a  much  different  method  of  analysis  illustrated  the 
business  processes  more  clearly. 

The  research  began  with  interviews  of  key  personnel.  Using  a  pre-planned  set  of 
questions  and  forms  (see  Figure  5.1),  these  interviews  were  intended  to  identify  specifics 
of  business  processes  and  provide  a  foundation  to  rank  order  the  suitability  of  a  process 
for  an  Intranet  solution. 
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ESU  Alameda  Process  Analysis 

Please  pick  one  important  process  you  do  in  your  job  (i.e.  order  parts)  and  answer  these  questions.  Thank- 
you. 

ESU  Alameda  Process  Analysis  Interview 

|  What  is  your  Rank,  Rate  and  Job  Title?  | 


Please  pick  one  important  process  you  do  m  your  job  (i.e.  order  parts)  and  answer  these  questions.  JhantoSBJU 


What  is  this  process? 

Please  Describe  it  briefly. 

1 .  How  many  people  does 
this  process  affect? 

□  One  D  Two  0  3-5  P  6-10  0  10+  E 
Other 

1  20  +  EJ  Everyone  at  XJhit 

2.  Who  are  the  people  or 
things  that  are  affected  by 
this  process? 

3 .  How  does  this  process 
affect  them? 

1  20  +  Q;  Everyone  at  Ufoit 

6.  Who  is  the  primary 
owner  (doer)  of  process? 

7 .  How  often  is  this  process 
used? 

Ip:  Daily  gp  Weekfy  i£l  Monthly 

Other 

O  Quarterly  Q  Annual^ 

8 .  How  often  is  this  process 
updated? 

Ip  Daily  Ip.  Weekly  Ip:  Ma rtthly 

Other 

P  Quarterly  P  Annually 

9 .  Please  identify  some  key 
personnel  or  things  and 
how  they  interact  with 
this  process? 

PersonTThing 

10.  What  is  the  type  of 
information  or  data  input 
for  this  process? 

P  General  (i.e..  AL  COAST  massages) 

□  Private  or 

□  Classified  or 

P  Low  Volume  ar,P  Medium  Volume  or 

Jp:  Customized  (i.e.vgritingthe  Plan,  of  Day) 

□  Non-private 

D  Unclassified 

□  Hi^l  Volume 

1 1 .  What  is  the  current  status 
of  data  storage  and 
computer  or  network 
automation  of  this 
process? 

EJ  Manual  (i.e.  using  desk  folders,  filing  cabinets,  etc.) 
ri  T>*rtTy  Antn™«r*H  faari-rirtvrraUfid  <t«ndAlnne  computer'! 

•  Using  Ward  Processing  files 

•  Using  Database 

n  TOill y  Arrtr™*tAH  £isin£  non-neharmked  sfcmdaltme  computer'! 

O  FulV  Antnnjirted  stud  Netwmkedwith  links  to  other  processes 

•  Computers  exchange  information,  files ,  data  with  other  people  or  processes 
□  Already  on  the  Intranet 

12.  Comments  or  anv  other 

Figure  5.1  Original  Process  Interview  Questionnaire 


Using  the  prepared  interview  questionnaires  was  not  as  successful  as  anticipated. 


Personnel  were  unable  to  clearly  articulate,  in  words,  the  specific  information  flows  and 
processes  of  their  day  to  day  work.  One  on  one  interviews  failed  to  produce  useful 
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information  until  the  approach  was  modified  to  drawing  pictures  that  modeled  an 
employee’s  daily  processes. 

The  most  valuable  method  of  understanding  the  ESU  Alameda  organization  and 
business  process  flows  was  to  talk  through  the  jobs  of  key  personnel  by  drawing  them  on 
whiteboards  as  Data  Flow  Diagrams  (DFD).  The  DFDs  helped  ESU  employees  articulate 
what  information  flowed  to  whom,  why,  where  it  was  stored  and  how  it  was  used.  The 
parts  and  supply  ordering  process,  for  example,  was  so  complicated  that  it  was  almost 
impossible  to  describe  without  using  a  drawing.  The  process  is  shown  in  Figure  5.2  as  a 
DFD. 
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Figure  5.2  DFD  of  Supply  and  Parts  Ordering  Business  Process 

From  the  visual  DFD  maps,  it  was  possible  to  redesign  the  system  by  looking  at 
how  entire  processes  and  information  flows  could  be  redirected  with  the  communications 
potential  of  an  Intranet  system.  New  methods  of  data,  information,  and  workflow  were 
conceived.  In  most  cases,  the  new  designs  did  not  simply  automate  the  original  DFD, 
rather  they  obliterated  the  old  DFD.  Redesigning  processes  necessitated  a  fresh  DFD  to 
accurately  portray  new  information  flows.  For  example,  new  DFDs  of  the  Intranet 
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solution  to  the  supply  process  were  developed  which  significantly  reduce  the  complexity 
found  in  Figure  5.2.  (See  Figures  5.5  through  5.7  for  the  new  DFDs.) 

C.  ESU  ALAMEDA  BUSINESS  MODEL 

1.  Overview 

ESU  Alameda  is  responsible  for  the  maintenance  and  support  of  all  electronics 
throughout  their  Coast  Guard  geographic  area  of  responsibility.  They  are  a  mid-sized 
service  oriented  organization  with  roughly  50  employees.  They  are  a  fairly  typical  USCG 
unit  with  most  of  the  same  pressures,  procedures,  and  paperwork  of  any  other  unit. 

2.  ESU  Customers 

The  ESU  has  internal  and  external  customers  who  could  benefit  from  Intranet, 
solutions  to  day-to-day  business  needs. 

Internal  customers  can  be  grouped  in  many  ways,  from  command  or  management 
level  to  the  office  worker.  Internal  customers  could  be  grouped  by  rank,  civilian  or 
military.  Internal  customers  have  different  needs  depending  on  which  group  they  belong 
to. 

Its’  external  customers,  those  whom  the  ESU  provides  services  for,  would  be 
interested  in  ESU  products  and  news  relevant  to  their  service  requests.  Other  external 
customers  could  be  anyone  who  needs  to  reach  the  internal  employees  of  the  ESU. 
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3.  Organization 


ESU  Alameda  is  a  typical  hierarchical  organization  organized  in  a  tree  structure. 
It  has  a  military  chain  of  command  beginning  with  the  Commanding  Officer  (CO)  and 
Executive  Officer  (XO)  at  the  top.  The  ESU  is  then  divided  into  distinct  divisions,  or 
branches,  with  a  Division  Head  in  charge  of  each. 


4.  Information  Flows 

Approval  authority  for  ESU  policy  decisions,  personnel  actions  or  budget 
allocation  follows  the  traditional  military  chain  of  command.  Final  responsibility  for  all 
decisions  at  the  Command  rests  with  the  CO. 

The  CO  delegates  his  authority  as  appropriate.  ESU  Alameda  considers  itself  an 
innovative  organization.  Despite  the  traditional  hierarchical  structure,  information  flows 
are  not  strictly  linear.  The  CO  states  clearly  in  the  ESU  Standard  Operating  Procedures 
that  he  expects  employee  empowerment  and  communication  across  organizational 
boundaries. 

“My  intent  is  ...  to  encourage  action  and  decision  making  at  all  levels...  Use  the 

organizational  chart  as  a  starting  point;  it's  not  set  in  stone...  (p.2.  Lane,  1996)” 

5.  Business  Model  Analysis 

The  business  model  analysis  was  approached  from  a  high  level  of  abstraction 
where,  first,  the  fundamental  mission  of  the  organization  was  identified.  Following  that, 
the  long-term  goals  that  support  the  mission  were  ascertained.  Next,  the  critical  success 
factors  necessary  to  accomplish  the  long-term  goals  were  found.  Finally,  the  specific 
processes  that  contributed  to  each  critical  success  factor  were  determined.  Figure  5.4 
provides  a  snapshot  of  this  analysis. 
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Missions 
ZJSCG  ESU 
Alameda  is 
responsible 
for.. 

Goals 

To  accomplish  the 
mission,  VSCG 
Alameda's  goal  is 
to... 

Critical  Success  Factors 

To  be  successful  and  accomplish  the  goal,  VSCG 
Alameda  must  have... 

Processes 

To  be  successful,  these  processes 
occur.. 

Providing 
world  class, 
top  quality 
electronic 
support  to 
customer 
units 

Ensure  operational 
readiness  of  all 
mission  essential 
equipment  onboard 
USCG  units  in  the 
area  of 
responsibility 

•  Means  to  determine  inventory,  parts,  and 
supply  order  status. 

•  Means  to  anticipate  personnel 
administrative  needs  and  whereabouts  far 
enough  in  advance  to  budget  these  costs 

•  Means  to  determine  status  and  location  of 
outstanding  Casually  Reports  (CASREPS) 

•  Means  to  track  results  of  repairs  and 
customer  satisfaction 

•  Means  of  communicating  with  internal  and 
external  customers 

=>  Track  supply  order  chain 
=>  Track  and  forecast  current 
personnel  whereabouts  and  admin 
=>  Information  flow  to  ESU  to 
maintain  database  with  current 
outstanding  CASREPS  and  work 
orders 

=>  Measure  customer  satisfaction 
and  store  data 

Measure  trouble  calls  and  store 

data 

Figure  5.4  ESU  Alameda  Business  Model  Chart 

This  systems  thinking  approach  to  analysis  was  intended  to  eliminate  noise  by 
identifying  the  truly  important  processes,  which  could  be,  traced  back  to  supporting  the 
ESU’s  mission.  Business  practices  that  were  not  aligned  with  the  ESU’s  strategic  goals, 
or  did  not  add  value  to  the  ESU’s  critical  processes,  were  not  considered  candidates  for 
Intranet  solutions. 


D.  CRITERIA  FOR  SELECTION  OF  INTRANET  SOLUTIONS 


1.  Command’s  Top  Goals 

So  many  processes  were  suitable  for  Intranet  solutions  that  the  scope  had  to  be 
narrowed  in  order  to  have  any  reasonable  chance  of  accomplishment.  The  Command’s 
top  goals,  or  problems  to  manage,  were  clearly  uncovered  during  the  research.  The  top 
three  were  found  to  be: 

•  keeping  track  of  personnel  movements  and  administration 

•  improving  the  supply  ordering  and  procurement  process 

•  status  monitoring  of  Casualty  Report  (CASREP)  service  requests 
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The  development  effort  concentrated  on  broadly  meeting  the  top  goals  of  the  ESU 
Command  rather  than  focusing  on  a  specific  workgroup’s  narrowly  defined  problems. 
The  high  level  focus  makes  the  most  sense  from  a  systems  perspective  because  the 
Command’s  priority  processes  are  global,  meaning  their  impact  stretches  throughout  the 
entire  organization. 

2.  Feasibility 

The  scope  of  the  Intranet  project  was  limited  on  a  practical  basis  due  to 
constraints  such  as  limited  time,  technical  feasibility,  and  developer  skill.  The  difficulties 
of  turning  a  logical,  or  conceptual,  design  into  a  reality  were  significant.  These 
constraints  are  addressed  in  Chapter  III. 

3.  Showcase  Intranet  Potential 

Bearing  in  mind  that  one  goal  of  this  thesis  is  to  demonstrate  the  power  of  an 
Intranet  for  a  Coast  Guard  unit,  it  follows  that  one  of  the  criteria  for  selection  of  Intranet 
processes  was  to  showcase  the  potential  and  capabilities  of  the  technology.  Applications 
that  could  change  the  organization,  obliterate  inefficient  processes,  or  distribute 
information  horizontally  across  departments,  were  conceived.  The  CO’s  principle,  as 
stated  in  the  SOP,  to  “allow  maximum  flexibility  ...  for  action  and  decision  making  at  all 
levels”  was  guiding,  (p.l,  Lane,  1996)  ' 
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E. 


LOGICAL  DESIGN 


1.  Requirements  Analysis 

Informal  requirements  analysis  was  used  because  the  goal  of  the  project  was  to 
demonstrate  the  capabilities  of  a  new  technology  and  the  requirements  were  unclear.  The 
business  model  was  examined,  as  described  above,  and  an  informal  conceptual  idea  of  the 
desired  functionality  was  attained.  Informal  requirements  analysis  was  a  continual 
process  of  refinement  because,  basically,  people  did  not  know  what  an  Intranet  is  so  they 
could  not  articulate  firm  requirements  for  one.  This  is  why  one  simple  goal  of  the  project 
is  to  build  a  prototype  and  demonstrate  what  is  possible. 

2.  Data  Flow  Diagrams 

Data  Flow  Diagrams,  resulting  from  research  into  the  ESU  business  model 
revealed  the  critical  elements  of  ESU  business  practices.  It  was  then  possible  to  imagine 
new  methods  of  doing  business,  and  new  DFDs,  that  take  advantage  of  Intranet 
technologies.  These  new  logical  designs  change  many  elements  of  the  process  including 
the  forms  used,  the  persons  involved,  and  the  roles  played  by  each. 

The  chaotic  complexity  of  the  parts  ordering  system,  as  seen  earlier  in  Figure  5.2, 
is  significantly  changed  when  remodeled  with  Intranet  technologies.  The  new  DFD 
redefines  the  roles  of  the  storekeeper  and  the  person  who  places  an  order.  In  the  new 
DFD,  the  person  placing  the  order  has  more  information  immediately  available  to  them, 
but  they  also  must  take  more  responsibility  for  personally  tracking  the  order’s  status. 
This  alleviates  time  the  storekeeper  previously  spent  tracking  orders. 
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Figure  5.5  Level  O  DFD  for  Entering  Intranet 

In  the  Context  Level  DFD  shown  in  Figure  5.7,  either  an  internal  or  external  user 
enters  the  ESU  Intranet. 

- Tu  InUaiml - ► 

|  pyisuiuiel  IiiTui.ciuii.uuii — 

4 - - - 

Administrative  Database 
Request 


Figure  5.6  Level  1  DFD  for  Intranet 

In  the  Level  1  DFD,  the  Intranet  user  can  select  to  enter  the  Supply  application. 


Request 

Administrative 

Database 


~  .  i  -r  .  .  .  W 

Query  Intranel 
Database 

■uippiy  u  aiaoase  nequesT 

— * — 

Information 

Request 

Supply 

Database 

Figure  5.7  Level  2  DFD  of  Supply  Application 

The  Level  2  DFD  shows  the  logical  information  flow  for  a  Supply  database 
application.  This  new  model  greatly  reduces  the  complexity  of  the  original  supply  and 
parts  ordering  processes  shown  earlier  in  Figure  5.2. 

New  DFDs  that  incorporate  Intranet  solutions  were  developed  for  other  processes 
uncovered  during  analysis.  They  included  DFDs  for  personnel  administration,  leave 
tracking  and  distributing  communications. 

The  decomposition  of  the  processes  beginning  from  a  high  level  of  abstraction 
and  working  down  into  the  details  of  the  process  clearly  illustrates  the  systems  focus  of 
the  Intranet  logical  design.  DFDs  were  crucial  to  understanding  the  information  flows  of 
the  system.  They  provided  excellent  conceptual  blueprints  of  the  system  processes  and 
interrelationships,  as  well  as  good  starting  points  for  actual  physical  design. 
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3.  Desired  Functionality 


The  desired  functionality  of  a  prototype  Intranet  was  determined  by  the  criteria 
indicated  above;  the  command’s  top  goals,  feasibility,  and  a  showcase  for  the  potential  of 
Intranet  technology.  Using  those  guidelines,  the  developer  settled  on  several  functional 
application  concepts  for  the  Intranet.  They  are  listed  here  in  a  table  with  the  desired 
logical  application  and  the  selection  criteria. 


Application 

Does  it 

Addresses 
Command’s  Top 
Goals? 

Is  it  Technically 
Feasible? 

Does  it  Showcase 

Intranet 

Technology? 

Leave  Request 

yes 

yes 

yes 

Phonebook 

yes 

yes 

yes 

Customer  Service  Hotline 

yes 

yes 

yes 

Supply  Tracking 

yes 

somewhat 

yes 

Temporary  Assigned  Duty 

yes 

yes 

yes 

Personnel  Reports 

yes 

yes 

yes 

File  Uploads/Downloads 

yes 

yes 

yes 

On-line  Discussion  Forum 

yes 

yes 

yes 

CASREP  Tracking 

yes 

yes. 

yes 

Figure  5.  8  Logical  Applications  with  Criteria  for  Selection 


4.  Functional  Partitioning 

Functional  partitioning  is  a  process  of  describing  what  a  system  is  intended  to 
accomplish,  and  then  breaking  the  system  into  the  components  that  will  do  it.  The 
desired  functionality  of  the  Intranet  is  shown  in  Figure  5.9  as  a  functionally  decomposed 
logical  design.  This  method  of  logically  viewing  a  system  is  neat  and  modular  which 
provides  a  good  starting  point  for  the  actual  physical  design.  All  of  the  components  that 
were  anticipated  for  development,  starting  with  the  top  “system  level”,  and  layering 
down,  are  shown. 
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Security 

Login  and 

Passwords 

Policy 

Figure  5.9  Functional  Decomposition  Diagram  of  ESU  Intranet 

This  functional  decomposition  diagram  was  a  major  product  of  the  logical  design 
phase  of  ESU  Intranet  development.  The  diagram  includes  all  the  system  design  goals 
without  regard  to  actual  physical  design,  software  or  hardware  platform. 

F.  CONCLUSION 

This  chapter  described  the  process  of  research' and  analysis  of  the  ESU  Alameda 
business  model.  The  criteria  for  selection  of  Intranet  processes  were  introduced  and  the 
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logical  design  of  an  Intranet  system  was  presented.  The  end  of  the  Analysis  Phase 
marked  the  demarcation  point  between  concept  and  reality.  The  first  five  phases  of  the 
Waterfall  Model  resulted  in  a  logical  picture  of  the  desired  system.  What  remained  ahead 
was  the  hard  work  of  building  the  system  to  the  blueprint. 
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VI.  SOFTWARE  TOOLS 


A.  INTRODUCTION 

Specific  software  tools  are  required  to  create  an  Intranet.  All  Intranet  users 
require  a  Web  browser  to  view  Web  pages  on  the  site.  The  developer  must  have  a  tool  to 
design  individual  Web  pages  as  well  as  to  visually  develop  an  organized  Intranet  site 
layout  and  navigation  scheme.  A  database  program  is  necessary  to  store,  query  and  add 
Intranet  data  to.  The  middleware  component  facilitates  interaction  between  a  Web 
browser  and  a  database.  Finally,  an  Internet  Web  Server  is  required  to  host  the  Intranet 
site. 

B.  SOFTWARE  TOOLS 

1.  General  Selection 

The  criteria  for  selecting  software  tools  included  assessing  cost,  availability,  ease 
of  use,  functionality  and  compatibility  with  current  Coast  Guard  platforms.  A  complete 
Microsoft  solution  was  chosen  primarily  because  their  software  tools  met  all  of  those 
criteria.  Microsoft’s  tools  were  easy  to  learn,  they  were  available  at  no  cost,  and  each 
product  seamlessly  integrated  with  another.  As  well,  Microsoft  Windows  NT  and 
Microsoft  Office  Suite  are  the  official  standard  Coast  Guard  operating  system  and  office 
tools,  respectively. 
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The  software  tools  necessary  and  the  ones  chosen  are  listed  below: 


Software  Tool: 


Version  Used: 


Microsoft  Internet  Explorer  4.0 
Microsoft  Front  Page  98 
Microsoft  Access  97  (ODBC  Compliant) 
Microsoft  Active  Server  Pages  1 .0 
Microsoft  Internet  Information  Server  3.0 
Microsoft  Windows  NT  4.0 
Microsoft  ODBC 
ASPMail  2.5 


Figure  6.1  Software  Tools  Chosen  for  Intranet  Development 


2.  WebBrowser 

An  Intranet  is  viewed  through  any  standard  Web  browser.  Web  browsers  translate 
the  coded  text  files,  mostly  written  in  Hypertext  Markup  Language  (HTML),  into  graphic, 
pages  displayed  in  the  browser’s  window.  One  of  the  most  powerful  features  of  a  Web 
browser  is  that  it  provides  a  standard  application  interface  for  any  Internet  or  Intranet 
content,  regardless  of  the  hardware  platform  the  Web  browser  is  running  on. 

Internet  Explorer  4.0  (IE4)  was  chosen  for  its  easy  integration  with  other 
Microsoft  Office  applications,  its  stability,  its  support  for  Web  scripting  languages,  and 
its  optimal  suitability  for  interfacing  the  Microsoft  Active  Server  Pages  middleware 
component. 

The  other  alternative  was  to  adopt  Netscape  Communicator.  There  are,  in  fact, 
only  very  minor  differences,  such  as  slight  color  variations  and  small  differences  in  where 
graphics  are  displayed,  in  the  way  Web  pages  appear  in  the  different  browser  windows. 
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One  of  the  most  significant  features  of  the  Intranet  is  that  it  is  platform  and  Web 
browser  independent.  It  can  be  viewed  on  any  standard  Web  browser.  The  Intranet  is 
only  optimized  for  IE4  in  the  sense  that  the  day  to  day  testing  and  development  effort  was 
done  using  IE4. 

3.  Web  Page  Authoring  and  Web  Site  Management 

Web  pages  are  the  essential  components  of  the  Intranet  site.  The  Web  page 
authoring  tool  is  the  most  frequently  used  software  tool  for  the  site’s  development  and 
management. 

Requirements  for  selection  of  this  tool  included  ease  of  use,  reliability, 
standardization  and  site  management  capabilities.  Front  Page  98  (FP98)  was  chosen  as 
the  Web  site  and  Web  page  authoring  tool  because  of  its  strong  support  for  total  site 
management.  It  seamlessly  integrates  with  the  other  Microsoft  products  such  as 
Windows  NT,  Windows  95,  Internet  Explorer  4.0,  and  Active  Server  Pages.  The  visual 
development  environment  of  FP98  was  easy  to  use  and  learn.  The  development  interface 
also  allows  for  immediate  access  to  the  raw,  underlying  HTML  code.  Access  to  HTML 
code  is  necessary  because  some  elements  of  Web  page  design  cannot  be  accomplished 
through  a  visual  interface  alone. 

An  alternative  to  FP98  is  Net  Object’s  Fusion  site  tool.  Fusion  has  a  very 
intuitive  visual  interface  for  Web  page  and  site  design.  Fusion  was  not  chosen  because, 
before  publishing  to  the  Web  server,  it  pre-stages  the  visual  layout  of  a  Web  page  and  site 
in  a  proprietary  file  format  called  NOF.  It  isn’t  possible  to  edit  underlying  HTML  code 
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when  the  files  are  stored  as  NOF  files.  Since  it  is  sometimes  important  to  access  HTML 
code  while  programming,  Net  Objects  Fusion  was  not  a  good  solution. 

4.  Databases 

Database  development  was  with  Microsoft  Access  97.  Familiarity  with  the 
product,  the  fact  that  it  is  in  everyday  use  at  the  sponsoring  command,  and  the  fact  that  it 
is  a  Microsoft  product  were  the  leading  criteria  for  its  selection  as  the  Intranet  database 
tool.  Access  97  is  designed  for  a  small  office  environment  but  can  easily  scaled  up  to  a 
more  powerful  tool  like  Microsoft  SQL  Server. 

Access  97  is  Open  Database  Connectivity  (ODBC)  compliant.  ODBC  is  a 
standardized  interface,  which  allows  applications  to  have  access  to  the  data  inside  a 
variety  of  different  databases,  regardless  of  their  unique  formats.  ODBC  provides  a 
middle  layer  that  hides  the  differences  between  database  formats  (Fleet,  Warren,  Chen, 
Stojanovic,  78). 

Any  ODBC  compliant  database,  such  as  those  offered  by  IBM,  Oracle  or 
Informix,  could  be  used  on  the  Intranet.  These  options  are  designed  for  enterprise  wide 
applications  and  were  considered  beyond  the  scale  of  this  small  project. 

5.  Middleware 

Middleware  provides  the  language  for  communication  between  a  database  on  a 
server  and  the  pages  generated  dynamically  and  output  to  a  client’s  Web  browser. 
Deciding  on  a  powerful,  yet  easy  to  use,  middleware  solution  is  a  crucial  decision  for  the 
Intranet  developer.  This  project  uses  Microsoft’s  Active  Server  Pages. 
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The  field  of  alternatives  is  wide.  There  were  many  alternatives  for  large  database, 
enterprise  wide  solutions  from  Oracle  and  Informix.  These  solutions  were  more 
appropriate  for  large  mainframe  based  operations.  For  the  mid-sized  organization, 
middleware  products  such  as  IBM’s  Domino  and  Microsoft’s  SQL  server  compete.  The 
alternatives  for  a  small  office  setting  included  Allaire’s  Cold  Fusion  and  Microsoft’s 
Active  Server  Pages  (ASP).  Both  Cold  Fusion  and  ASP  can  be  scaled  to  larger  settings, 
all  the  way  up  to  enterprise.  The  enterprise  products,  however,  were  considered  too 
powerful  for  this  thesis. 

Cold  Fusion  is  arguably  the  most  established  middleware  product  available  today. 
Allaire’s  most  recent  version  even  includes  a  visual  development  tool  for  Web  enabling 
databases.  Cold  Fusion  has  been  on  the  market  for  several  years  and  is  currently  in  use 
by  such  companies  as  Federal  Express,  Dell  Computer  and  Ticketmaster  (Forta,  1997). 

Microsoft’s  Active  Server  Pages  middleware  product  is  relatively  new.  The  term 
Active  Server  Pages  is  less  than  two  years  old.  Microsoft  currently  has  no  visual  tool 
available  for  writing  ASP  code  and  everything  must  be  handwritten  using  a  text  editor. 

Both  ASP  and  Cold  Fusion  are  middleware  products  that  run  on  a  host  server  and 
are  very  similar  in  their  implementation  and  execution.  The  code  is  executed  on  the  Web 
server,  which  will  then  query  a  database,  and  finally  dynamically  generate  a  Web  page 
based  on  that  query. 

The  primary  criteria  which  led  to  the  selection  of  one  product,  Microsoft’s  Active 
Server  Pages,  over  another,  Allaire’s  Cold  Fusion,  was  cost.  Microsoft’s  product  is  free 
and  will  run  on  any  Windows  NT  server  where  ASP  is  installed.  Cold  Fusion  costs  close 
to  one  thousand  dollars  per  license. 
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Other  criteria  included  Microsoft’s  implementation  of  Visual  Basic  Script 
(VBSript)  as  the  language  to  manage  the  interactions  between  the  Web  server  and  client. 
VBSript  is  an  extension  of  the  Visual  Basic  language,  which  is  widely  supported.  New 
components  that  work  with  ASP  are  constantly  being  developed  and  sold  by  third-party 
vendors  other  than  Microsoft.  Cold  Fusion,  in  contrast,  uses  a  proprietary  scripting 
language  and  specialized  “tags”  throughout  for  its  code. 

6.  Internet  Web  Server 

The  Internet  Web  Server  hosts  the  site.  Microsoft’s  Internet  Information  Server 
3.0  (IIS)  was  the  natural  choice  because  it  is  free  as  an  integral  part  of  the  Windows  NT 
4.0  operating  system.  Windows  NT  4.0  is  the  Coast  Guard’s  official  standard  operating 
system.  ASP  was  also  designed  to  run  on  IIS. 

C.  CONCLUSION 

The  software  choices  made  here  determined  the  shape  of  the  resulting  Intranet 
product.  These  tools  have  both  their  strengths  and  limitations  when  compared  with  other 
tools.  Nevertheless,  they  all  met  the  most  important  criteria  for  selection,  which  was 
cost,  ease  of  use,  functionality,  and  quality. 
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VII.  PHYSICAL  DESIGN 


A.  INTRODUCTION 

Physical  design  is  the  fifth  phase  of  the  Waterfall  Model.  The  physical  design 
phase  took  four  months  of  development  effort  during  which,  the  prototype  Intranet  was 
physically  built.  Intranet  applications  took  shape  through  an  iterative,  Rapid  Prototype 
process  of  design  and  redesign. 

This  chapter  briefly  describes  the  technical  aspects  of  physically  building  an 
Intranet.  A  tutorial  on  how  to  connect  to  a  database  through  a  Web  browser,  using  Active 
Server  Pages,  is  presented  here.  Finally,  graphic  user  interface  design  principles  and 
security  aspects  of  the  Intranet  are  discussed  in  this  chapter. 

B.  PHYSICAL  DESIGN  STEPS 

Turning  an  Intranet  concept  into  a  reality  requires  following  certain  general  steps. 
This  following  section  describes,  as  a  short  tutorial,  the  basic  design  steps  for  a  Windows 
NT  based  Intranet  using  Active  Server  Pages. 

1.  Web  Server 

A  Web  server  must  be  installed  on  the  machine  that  will  host  the  Intranet  site. 

2.  Web  Authoring  Tools 

Web  authoring  tools  used  to  build  the  site  must  be  installed  on  the  Intranet  design 
machine.  The  machine  must  be  on  the  network  in  order  to  publish  to  the  Web  server. 
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3.  Middleware 


The  middleware  component  that  will  allow  an  ODBC  compliant  database  to 
communicate  with  a  Web  server  must  be  installed. 

4.  Database 

A  database  to  hold  Intranet  data  must  be  developed.  Care  should  be  taken  to  note 
the  design  details,  such  as  table  and  field  names,  as  familiarity  with  the  data  structures  is 
crucial  to  allow  the  Intranet  to  interact  with  them. 

5.  Data  Source  Name  (DSN) 

Using  the  ODBC  control  panel  from  the  Windows  Operating  System,  Data  Source 
Names  (DSN)  for  the  databases  must  be  created.  These  names  will  be  used  in  the 
middleware  code  to  reference  the  Intranet  databases. 

6.  Intranet 

The  physical  design  should  follow  the  logical  blueprint.  Authoring  Web  pages 
and  building  a  site  layout  creates  the  Intranet.  Some  of  the  Web  pages  may  use  scripting 
code  and  to  communicate  with  a  database  (through  middleware)  for  information  retrieval, 
queries  and  updates. 
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C.  CONNECTING  TO  A  DATABASE  WITH  ASP 


1.  Introduction 

This  section  is  a  brief  introduction  of  how  to  connect  to  a  database  through  the 
Web  browser  using  Active  Server  Pages.  The  example  only  provides  a  very  basic 
overview  of  the  most  general  method  used  to  do  this  on  the  ESU  Alameda  Intranet. 

The  examples  found  here  show  the  ASP  code  as  it  is  written  into  the  Web  page. 
The  code  for  ASP  pages  are  found  only  on  the  server  because  the  server  uses  the 
underlying  ASP  code  to  dynamically  generate  HTML  code  when  a  page  is  requested. 
The  client  browser  that  initiates  a  request  to  the  Web  server  never  sees  the  ASP  code. 


2.  Database 


An  Access  database  used  on  the  ESU  Intranet  is  called  “phonebook.mdb”.  The 
database  has  several  tables.  This  tutorial  will  focus  on  one  table  called  PERSON,  which 
contains  fields  for  employee  data. 


m 

PERSON  :  Table 

Field  Name 

Data  Type'  !  1®: 

Description 

Rank 

Text 

Enter  the  rank  of  the  CG  person 

Rate 

Text 

Enter  the  rate  of  the  CG  person 

FirstName 

Text 

Enter  the  first  Name  of  the  person 

Middlelnit 

Text 

Enter  the  middle  initial  of  the  person 

— 

LastName 

Street  . . __ . . . . . 1 

City . . . . . . . j 

State 

Text 

Text 

Text 

Text 

Enter  the  Last  name  of  the  person  . 

Enter  the  street  address  of  the  person  . . . . 

Enter  the  city  the  person  lives  in 

Enter  the  state  the  person  lives  in 

> 

. __ . _  .  . . . 

Text 

Enter  the  zip  code  at  the  person's  living  quarters 

Figure  7.1  Person  Table  of  Phonebook  Database 
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3.  ODBC  and  the  Data  Source  Name 


This  database  has  been  configured  as  an  ODBC  compliant  DSN  with  the  name 
“phonebook”.  The  DSN  name  is  important  to  remember  because  it  is  used  to  reference 
the  database  in  the  ASP  code. 


liir  w&mm  -  mm 


User  DSN  System  DSN  ]  R|e  DSN  |  ODBC  Drivers  |  Tracing  |  About  ) 
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ODBC  Microsoft  Access  97  Setup 


Data  Source  Name: 


Phonebook 


OK 


Description:  ]ESU  Personnel  Database 


•V  ti: 

r  Database 


Cancel 


.....  .  ...  ^.. 

■  =;!V ' .:  •"  i's\! 


Database:  c:\online  databases\pbemebook.mdb 

Select..  Create...  |  Bepair...  |  Compact..  j 


Help 


Advanced... 


Figure  7.2  ODBC  System  DSN  Setup  Window 


4.  Connection  Object 

ASP  code  is  written  in  Visual  Basic  script.  In  this  example,  a  connection  object  is 
instantiated  and  named  Conn.  The  connection  is  made  to  the  ODBC  DSN  “phonebook”. 
Objects  can  have  properties  about  them  and  methods  that  act  on  them.  In  this  case,  the 
open  method  is  used  on  the  connection  object. 

<%'  //  Set  up  connection  and  open  it 

Set  Conn  =  Server. CreateObject("ADODB. Connection") 

Conn. Open  "Phonebook"  %> 
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5.  Recordset  Object 


The  recordset  object  is'  used  primarily  to  store  the  results  of  a  database  query.  It 
may  be  thought  of  as  a  virtual  table  in  memory,  made  up  of  rows  and  columns.  In  this 
example  a  recordset  object  is  instantiated  and  given  the  name  rs. 

<% '  //  Set  up  recordset 

Set  RS  =  Server.CreateObject("ADODB.RecordSet")  %> 

6.  Define  SQL 

The  Structured  Query  Language,  SQL,  for  the  desired  database  query  is  assigned 
to  a  variable  named  SQL  in  this  example. 

<%'// Define  SQL 

SQL  =  "SELECT  FirstName,  LastName  FROM  Person"%> 

7.  Execute  the  Query 

Using  the  recordset  open  method,  the  SQL  query  can  be  executed. 

<%'  //  Rim  Query 

RS.Open  SQL,  Conn  %> 

8.  Display  the  Results 

Finally,  the  results  of  the  SQL  query,  which  are  stored  in  the  recordset  object  "rs", 
can  be  displayed.  The  response. write  command  (composed  of  a  response  object  and  its 
write  method)  is  used  to  display  the  contents  of  the  recordset.  A  Visual  Basic  loop,  the 
MoveNext  method,  and  the  End  of  File  property  are  used  to  loop  through  the  recordset 
until  all  records  are  displayed. 
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<% '  //  Write  each  row 


DO  WHILE  NOT  RS.EOF 

response.write  RS("LastName")  &  ",  " 
response.write  RS("FirstName")  &  "<BR>  " 

RS.MoveNext 

LOOP 

RS.close%> 

D.  GRAPHIC  USER  INTERFACE  DESIGN  PRINCIPLES 

1.  Introduction 

Simplicity,  consistency,  elegance,  content  and  usability  were  the  underlying 
Graphic  User  Interface  (GUI)  design  principles.  The  following  brief  list  highlights  some 
of  these  principles: 

•  Minimal  use  of  distracting  colors,  flashy  logos,  or  pictures. 

•  Focus  on  consistency  across  all  pages.  A  common  background  and  header  is 
used  on  all  Web  pages. 

•  Cautious  use  of  frames.  Frames  are  used  to  divide  the  Web  browser 
window.  Frames  are  tricky  to  program  and  can  be  distracting  and  annoying  if 
they  are  used  improperly.  The  ESU  Intranet  only  makes  use  of  frames  once, 
for  the  left  side  navigation  bar. 

•  Content  is  king.  Every  page  on  the  site  must  have  some  function,  purpose, 
or  utility  to  be  included  on  the  site. 
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The  design  principles  are  discussed  in  greater  detail  in  the  paragraphs  below.  Screen 
shots  of  the  Intranet’s  pages  are  presented  in  Chapter  VIII. 

2.  Consistency 

Consistency  was  key  in  designing  the  site.  Every  page  has  a  consistent  visual 
background,  color  scheme  and  titles.  Tasks  performed  within  specific  applications  are 
performed  in  a  similar  manner  across  all  application  areas.  For  example,  submitting  an 
on-line  Leave  Request  in  the  Leave  Application  is  almost  identical  to  submitting  an  on¬ 
line  Temporarily  Assigned  Duty  (TAD)  Notification  in  the  TAD  Application. 

3.  Current  Content 

Currency  and  relevancy  was  another  important  GUI  design  principal.  The  most 
dynamic  data,  which  changes  with  the  greatest  frequency,  is  immediately  presented  up 
front  on  all  page  layouts.  For  example,  the  Intranet  Home  Page  presents  the  visitor  with 
the  most  current  data  from  four  application  areas.  At  a  glance,  the  visitor  can  see  who  is 
currently  on  leave,  who  is  currently  away  on  TAD,  what  general  announcements  have 
been  broadcast  for  the  command  and  what  user  access  level  they  are  logged  in  at.  The 
user  may  follow  hyperlinks  to  drill  down  into  more  details  of  this  data.  They  may  also 
scroll  down  the  Home  Page  for  other  information  that  changes  less  frequently.  All  pages 
across  the  Intranet  are  designed  with  the  principle  of  putting  the  most  current  and  relevant 
data  at  the  top  of  the  page.  A  link  is  included  to  further  drill  down  into  details  about  the 
data. 
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4.  Usability 


Usability  was  another  GUI  design  principle.  The  applications  were  designed  to  be 
used  intuitively  with  little  or  no  user  training  and  with  minimal  danger  of  user  errors.  All 
interactions  with  the  back-end  databases  are  through  a  common  Web  browser  interface. 
Anyone  who  is  familiar  with  using  a  standard  Web  browser  to  navigate  the  Internet 
should  have  no  difficulty  understanding  how  to  use  these  Intranet  applications.  A  user 
only  needs  to  know  how  to  follow  hyperlinks  and  to  submit  on-line  forms. 

The  only  foreseeable  areas  where  users  can  make  mistakes  is  in  either  the 
submission  of  on-line  forms  or  in  the  unintended  modification  or  deletion  of  on-line 
records.  In  submitting  on-line  forms  users  may  enter  invalid  datatypes  in  certain  fields 
which  could  cause  the  back  end  database  to  reject  the  entire  form.  Care  has  been  taken  in 
the  design  process  to  validate  data  before  it  is  submitted  to  the  database  to  minimize  this 
risk.  There  are  cases  however  where  data  validation  is  not  easily  implemented,  such  as 
validating  date  formats.  In  these  instances,  the  possibility  exists  that  the  user  may  enter 
invalid  data  or  an  unrecognized  format,  which  will  cause  an  error.  In  all  cases,  the  user 
has  to  redo  their  form  or  delete  the  erroneous  data. 

5.  Deletions 

All  deletions  across  the  Intranet  are  handled  in  the  same  manner.  Deleting  records 
is  not  a  simple  one-click  process.  The  user  is  clearly  informed  of  what  they  are  about  to 
delete  and  given  the  opportunity  to  back  out.  When  a  delete  request  is  made,  a  warning 
alert  box  pops  up  in  the  browser  window  which  informs  the  user  that  deleting  records  is  a 
serious  matter  and  should  only  be  performed  by  personnel  authorized  to  do  so.  The  user 
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must  click  “OK”  to  continue.  Next  the  user  is  presented  with  all  the  information  that  will 
be  deleted.  There  is  a  warning  banner  in  red  across  the  top  of  the  page.  A  cancel  button 
is  prominently  displayed  in  case  the  user  made  a  mistake.  Finally,  to  perform  the  delete 
the  user  must  press  a  very  large  red  button  that  clearly  indicates  they  are  about  to  delete  a 
record. 

Deleting  records  requires  deliberate,  informed  action  on  the  part  of  the  user.  The 
site  was  designed  so  that  there  is  very  little  possibility  that  the  user  will  mistakenly  delete 
data.  The  possibility  exists,  however  that  an  unauthorized  person  will  delete  records  that 
do  not  belong  to  them.  Backups  are  recommended  in  case  this  happens.  Command 
policy  on  acceptable  use  should  specifically  address  this  issue  of  unauthorized  deletion 
and  modification  of  data. 

6.  Site  Navigation  and  Menu  Bars 

A  left-hand  vertical  navigation  bar  is  implemented  as  a  frame  and  is  always 
present  in  the  Web  browser  window.  The  menu  bar  contains  links  to  general  application 
areas.  The  bottom  of  each  page  contains  a  horizontal  menu  bar  with  links  to  the  specifics 
in  each  of  the  application  areas.  The  menu  also  has  a  link  to  a  site  map,  which  displays 
all  links  available  to  Intranet  users. 

The  left-hand  navigation  menu  is  implemented  in  JavaScript.  This  enhances  the 
GUI  human  computer  interaction  because  the  links  change  color  when  the  mouse  pointer 
is  passed  over  them. 
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E. 


SECURITY  FEATURES 


1.  How  to  Use  the  Security  Features 

The  command  will  need  to  decide  on  at  least  four  username  and  password 
combinations  to  cover  the  four  security  access  privilege  levels.  These  levels  are  “sec 
admin”,  “admin”,  “user”  and  “guest”. 

A  visitor  to  the  Intranet  may  choose  to  log  in  at  one  of  the  security  levels 
(assuming  they  have  the  appropriate  username  and  password)  or  they  may  browse  the 
“Public  Access”  areas  of  the  site  that  are  available  to  the  “guest”  access  privilege  level. 

Once  a  user  has  successfully  logged  in,  a  variable  containing  the  security  access 
privilege  level  value  is  set  and  maintained  for  the  duration  of  their  visit.  The  variable  is 
temporarily  stored  as  a  cookie  in  the  Web  browser  using  the  Active  Server  Pages  session 
object.  The  session  object  stores  the  security  access  level  for  the  duration  of  a  visit.  It 
expires  when  the  visitor  exits  the  Web  browser  or  after  twenty  minutes  of  inactivity. 

•  Guest  access  is  the  default  access  level  for  anyone  who  has  not  logged  in  and 
is  browsing  the  “Extranet  -public  access”  areas  of  the  Intranet.  This  level  is 
intended  for  outside  visitors  and  anyone  who  is  not  a  part  of  the  ESU  unit.. 

•  User  access  is  the  default  access  level  for  anyone  who  is  a  member  of  the  ESU 
unit.  This  level  allows  access  to  most  areas  under  the  “Intranet  -  members 
only”  banner  of  the  menu  bar.  It  requires  logging  in  with  a  valid  username 
and  password.  All  members  of  the  unit  should  be  given  the  username  and 
password  for  this  access  level.  Logged  in  users  can  view  most  information  that 
is  specific  to  the  ESU  such  as  personnel  information  and  recall  logs.  Users 
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may  also  add,  edit  and  delete  most  records  contained  in  the  back-end 
databases.  Submitting  on-line  forms  such  as  leave  requests,  temporary  duty 
notifications,  and  the  posting  of  general  announcements  can  be  done  once 
logged  in  under  the  user  access  level. 

•  Admin  access  is  designed  as  the  default  access  for  supervisory  level  positions 
at  the  ESU.  This  level  is  used  to  restrict  access  to  pages  that  require  on-line 
approvals  of  forms  submitted  on-line.  Admin  access  allows  everything  that 
can  be  done  under  user  as  well  as  access  to  all  remaining  areas  of  the  site.  It 
is  recommended  that  a  limited  number  of  personnel  hold  this  access  level  as 
one  can  do  almost  everything  on  the  site  already  under  the  user  level.  Admin 
access  should  only  be  granted  those  persons  who  hold  supervisory  positions 
such  as  department  heads,  the  executive  officer  and  the  commanding  officer. 

•  Sec  Admin  access  is  the  highest  privilege  level.  This  level  is  designed  as  the 
top  level  primarily  for  administering  the  databases  and  deleting  sensitive 
records.  Only  one  or  two  people  should  have  sec  admin  access.  Presently, 
only  one  application,  deleting  a  personnel  record,  requires  this  access  level. 
Because  deleting  a  personnel  record  causes  a  cascade  delete,  where  the 
primary  record  and  all  related  records  are  deleted,  one  should  be  cautious  in 
who  has  access  to  the  delete  feature. 

2.  Security  Policy  Considerations 

The  command  is  encouraged  to  test  the  security  implementation  as  presented  and 
modify  it  as  necessary.  As  a  matter  of  policy,  the  command  may  want  to  further  restrict, 
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or  allow  greater  access  to  certain  information  contained  on  the  site.  The  command  may 
want  to  implement  individual  usernames  rather  than  the  four  generic  usernames. 

•  Usernames: 

The  default  Intranet  username  which  allows  user  access  should  be  distributed 
freely  to  all  members  of  the  ESU.  A  specific  warning  should  prohibit  ESU 
members  from  disclosing  the  username  and  password  to  anyone  who  is  not  a 
part  of  the  unit.  It  is  recommended  that  all  users  sign  a  form  to  attest  to  their 
compliance. 

•  On-line  “Digital  Signatures”: 

Many  on-line  forms  are  simply  automated  versions  of  an  equivalent  paper 
form.  These  forms  have  the  same  approval  chain  as  the  paper  forms  which 
were  previously  routed  through  the  various  inboxes  and  outboxes  of  the  ESU. 
Instead  of  a  pen  and  paper  signature,  these  forms  rely  on  a  “digital  signature”. 
The  digital  signature  generally  consists  of  no  more  than  a  check  in  a  box  and 
the  pressing  of  a  submit  button  in  the  Web  browser. 

Access  to  these  pages  where  approvals  occurs  is  limited  to  users  logged  in 
with  security  access  level  of  admin.  It  is  recommended  that  ESU  command 
policy  for  acceptable  use  of  the  Intranet  specifically  address  the  following: 
that  only  authorized  personnel  may  digitally  sign  (hit  the  submit  button)  on¬ 
line  forms  and  requests.  It  should  be  pointed  out  that  an  unauthorized  digital 
signature  on-line  is  the  same  as  forging  a  signature  on  the  equivalent  paper 
form.  Presently,  even  if  the  digital  signature  policy  was  abused,  it  would  not 
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cause  mission  critical  harm  (i.e.  no  money  would  be  misappropriated  or 
personnel  records  lost).  At  the  worst,  a  member  might  forge  his  or  her  own 
signature  for  a  leave  request.  Nevertheless,  the  viability  of  this  security  model 
for  “digital  signatures”  should  be  tested  and  policy  adjusted  accordingly. 

3.  How  Security  Works 

Usernames  and  passwords  are  stored  in  the  “phonebook”  database  under  a  table 
named  “users”.  Security  is  implemented  on  a  page  by  page  basis.  Every  request  for  a 
page  that  is  protected  will  first  be  redirected  to  a  security  access  level  check.  One  simple 
line  in  the  HTML  code,  called  a  “server  side  include”,  will  redirect  the  request  to  a  file 
which  is  executed  before  the  HTML  page  is  loaded.  The  include  file  contains  code  which 
checks  the  a  session  object  variable.  This  variable  stores  the  security  access  privilege 
level  variable  assigned  to  users  based  on  their  login.  Presently  there  are  three  server  side 
include  files  implemented  for  user,  admin,  or  sec  admin  access  respectively. 

1 .  <!--#include  file="../user_access.inc"--> 

2.  <!--#include  file="../admin_access.inc"--> 

3.  <!--#include  file="../secadmin_access.inc"--> 

Only  one  of  each  type  needs  to  be  included  before  the  HTML  header  for  pages  that  are  to 
be  protected. 

The  following  code  is  an  example  of  using  the  server  side  include  file  to  restrict 
access  to  a  page.  First  the  page  is  commented  with  an  Active  Server  Pages  header,  next 
the  server  side  include  file  is  in  bold,  and  finally  the  beginning  of  a  typical  HTML  page  is 
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shown.  If  the  user  successfully  negotiates  the  “adxnin_access.inc”  file  then  the  rest  of  the 
HTML  page  is  loaded.  Otherwise  the  user  is  redirected  to  a  “No  Access  Allowed”  page. 
<% 

'  *  For  every  page  that  you  want  to  enable  access  control,  put  the  include 
'  *  file  and  this  file  in  the  same  directory. 

'  *  Type  <!~#include  file- ’ . ./LoginCheck.inc"  ~> 

'  *  BEFORE  the  <html>  tag  (very  important)  at  the  top  of  the  page  you 
'  *  want  to  control  access  to.  %> 

<!— ^include  file="../admin_access.mc"--> 

<html> 

<head> 

<title>Pending  Leave  Requests</title> 

The  source  code  for  the  page  by  page  security  solution  was  taken  from  Jon  Mnemonic’s 
article  “Access  Control  With  a  Database”  published  on-line  at  "The  ASP  Hole". 

F.  CONCLUSION 

This  chapter  discussed  the  technical  details  of  the  physical  design  phase.  The 
actual  development  effort  took  months  of  ASP  and  HTML  code  programming. 
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VIII.  APPLICATIONS 


A.  INTRODUCTION 

This  chapter  shows  the  results  of  the  physical  design  phase,  which  are  the  Intranet 
and  its  applications.  The  Intranet  is  composed  of  over  80  custom  built  Web  pages. 
Screen  shots  of  important  pages,  with  brief  descriptions  of  how  the  applications  should  be 
used,  are  presented  here.  The  goal  is  to  present  the  reader  with  an  idea  of  the  basic  feel 
and  functionality  of  the  Intranet  application  areas. 

B.  APPLICATION  NAVIGATION  STRUCTURE 

The  navigation  menu  of  the  Intranet  is  arranged  functionally  by  application  area. 
Figure  8.1  shows  each  the  significant  pages  of  Intranet  and  how  they  are  navigated. 
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Figure  8.1  Intranet  Navigation  Structure 
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C.  HOME  PAGE 

The  ESU  Alameda  Intranet  Home  Page  is  the  starting  point  for  the  Intranet.  From 
the  home  page  the  user  may  login,  view  the  most  current  and  immediate  content,  or  jump 
off  to  any  of  the  various  Intranet  applications. 


0  Welcome  to  ESU  Alameda  Intranet  -  Microsoft  Internet  Explorer 


j  Fite  £dit  View  £o  Favorites  Help 

L  >  ■’Si' : . 

Back  I  Fcrwdrd  Stop  Refresh  Home 


://l  27.0.0.1  /prototype2/ 


M  '  sf-  0  '  «  'i-m  ■  M 

Search  Favorites  History  Channels  i  Fullscreen:  ;  Mail 


fectratte* 

Public  Accei's 


Electronic  Support  Unit  Alameda  Intranet 


Welcome  admin .  You  are  logged  in  with  security  level  admin 
General  Announcements  Personnel  on  Leave  Today 


fl  Announcement 


Posted  by  I  Name 


:  Allows  for  access  to  pages  intended 
;  for  ESU  menbers  only.  You  MUST ; 
;  login  to  tore  access  to  databases,  j 


username  :;||user 
Password:  | 

|Ebgin?| 


{Byrd,  Scott  CTC2) 
|  Fife,  Barney  (LT) 


5/1 0/98  USCGC  RELIABLE 
5/1 0/98  USCGC  Bittersweet 


OERs/Marks  Due  in  the  next  31  Days 

■»,  . .r  Whose  Marks  are 

m?  D„e 

|0 6  |5/10/98:  ,  .  ~~  j 

fe?  H6/1/98  :  Click  here  to  see  the 

|CW02  \6I\/9B  !  names  and  status  of  people 

.  — whose  marks  are  due. 


Plan  of  the  Week 

Click  Here! 
Today  is  5/4/98 


Figure  8.2  ESU  Alameda  Intranet  Home  Page 


D.  PERSONNEL  APPLICATION 

1.  Introduction 

The  purpose  of  the  Personnel  Application  is  to  track,  forecast,  and  manage 
information  about  ESU  Alameda  personnel.  The  application  interacts  with  the 
"phonebook"  database.  Access  to  this  application  is  restricted  to  users  who  have  logged 
in  at  the  security  session  level  "user".  Access  to  the  application  includes  the  ability  to 
view  records,  add  new  records  and  update  existing  records.  Only  users  logged  in  at  the 
highest  security  session  level  of  "sec  admin"  may  delete  records. 


Figure  8.3  Personnel  Administration  Application  Navigation  Structure 


2.  Web  Pages  of  the  Personnel  Application 

a.  List  of  Web  Page  Figures:  The  following  table  lists  the  names  of  the  Web 
pages  of  this  application  and  the  corresponding  figure  numbers. 


Web  Page 

Figure 

Welcome  Page 

8.5 

Lookup  Personnel  Details 

8.6 

Edit  or  Update  Personnel 

8.7 

Add  New  Personnel  On-line  Form 

8.8 

Delete  Personnel  Record 

8.9 

Figure  8.4  Table  of  Web  Pages  and  Corresponding  Figures 
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Electronic  Support  Unit  Alameda  Intranet 


Personnel  Administration  Web  Database  Application 


Select  a  name  from  the  pull  down  menu  and  click  "Lookup".  You  will  [Baker,  Jeff  (ET1) 
then  be  able  to  view,  edit  or  update  the  data  Lookup 


CanTt  find  your  record?  Click  Here  to  Add  new  personnel  to  the  database 


Complete  ESU  Personnel  Roster 


Name 


Baker,  Jeff  (ET1) 

Bartlett,  Rex  (ETC) 
Benhart,  Ralph  (LT) 
Bennett,  Damn  (SKC) 
Brewster,  Punkies  (AM2) 
Byrd,  Scott  CTC2) 

Cantu,  Edward  (TT3) 
Clarke,  Brian  (TCCS) 
DARDIS,  DEAN  (LT) 
Doolittle,  Doctor  (LT) 
Enberg,  Melvin  (TCI) 
Farms,  Toad  (LTJG) 
Farms,  653456  (LTJG) 
Farms,  dfgh  (LTJG) 

Fife,  Barney  (LT) 
Fontaine,  Trevor  (TT3) 
Gainer,  Joanne  (GS1 2) 
Gardner,  Bob  (ETC) 
George,  Joe  (ENS) 
Guiterez,  Laura  (ETC) 
Gunther,  Bobcat  (LCDR) 
Hamlin,  Chuck  (ETC) 


E-Mail 


thehannahs@thegrid.net 

thehannahs@thegrid.net 

thehannahs@thegrid.net 

thehannahs@thegridnet 

thehannahs@thegrid.net 

thehannahs@thegrid.net 

theharmahs@thegrid.net 

thehannahs@thegrid.net 

theharmahs@thegrid.net 

theharmahs@thegrid.net 

theharmahs@thegrid.net 

me@esu.alameda.cg 

me  @esu.  alame  da  eg 

me@esa  alameda.  eg 

theharmahs@thegnd.net 

theharmahs@thegrid.net 

theharmahs@thegrid.net 

theharmahs@thegrid.net 

theharmahs@thegnd.net 

thehannahs@thegrid.net 

theharmahs@thegrid.net 

thehannahs@thegrid.net 


ESU  Business  Services  Branch 
COTR  Branch 
Detachment  Oxnard 


details  edit  delete 
details  edit  delete 
details  edit  delete 


Business  Services  Branch  details  edit  delete 

Detachment  San  Pedro  details  edit  delete 


ERM  Branch 
IRM  Branch 
IRM  Branch 

Electronic  Systems  Branch 
ESU  Business  Services 
IRM  Branch 
Detachment  San  Pedro 
Detachment  San  Pedro 
Detachment  San  Pedro 
Detachment  San  Pedro 
IRM  Branch 
IRM  Branch 
Contracted  Source 


details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 


COTR  Branch 

COTR  Branch 

Detachment  Oxnard 

SoCal  Detachment  Organization 


details  edit  delete 
details  edit  delete 
details  edit  delete 
details  edit  delete 


Figure  8.5  Personnel  Administration  Welcome  Page 


b.  Welcome  Page:  The  Welcome  Page  presents  the  user  with  a  list  of  all  ESU 


Alameda  personnel.  Links  are  available  for  sending  email,  viewing  more  details,  editing 
or  deleting  personnel  records. 
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Electronic  Support  Unit  Alameda  Intranet 


Personnel  Details 


LT  Todd  Hannah 


SSN:  544699911 


Job  Title  Webmaster 

Department  Detachment  San  Pedro 

Work  Phone  ()  1234567  ext: 

E-Mail  thehannahs@thegrid.net 


Home  Information 


Address:  459  Chips  Way 

Monterey  CA  93955-5000 
Home  Phone  (408)6580989 

Beeper#;  Cell  Phone 

Leave  Requested 


edit  this  record. .  fill  out  an  online  leave  form  .  '  delete  this  record 

^  Personnel  Administration  Database  • 


I  Bater,  Jeff(ETl )  3 

Add  new  personnel  Lookup  Person  j  Personnel  A  rlrmfiktrati'vi  Date 


Figure  8.6  Personnel  Details 


c.  Lookup  Personnel  Details:  The  main  detail  page  provides  more  in  depth  detail 
of  each  person  in  the  database.  This  page  is  accessed  either  by  following  the  "details" 
link  from  the  Personnel  Database  Welcome  Page  or  by  using  any  of  the  personnel  lookup 
boxes  found  throughout  the  application. 
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Electronic  Support  Unit  Alameda  Intranet 


Update  or  Edit  Personnel  Details 

Rank  Rate  First  Name  M[ 


Last  Name 


SSN 


03  1*  LT 

Todd  |  R  ;  Hannah 

544699911 

[Work  Mornation  I 

Job  Title  Webmaster 

Department 
Work  Phone 
E-Mail 


Detachment  San  Pedro 


1234567 


i  ext: 


jthehannahs@thegrid.net 


ome  Information 


Address: 

Street 

459  Chips  Way 

City,  State,  Zip 

Monterey 

CA 

[93955-5000! 

Home  Phone 

Beeper# 

|5675678 

1  Update  Data  |  Reset 

fill  out  an  online  leave  form 

Add  new  personnel 


)  Baker,  Jeff  (ET1)  1 

’eiscm 


delete  this  record 


Personnel  Administration  Database 


Figure  8.7  Edit  Personnel  Details 

d.  Edit  or  Update  Personnel:  This  page  allows  users  to  edit  or  update  their  own 
record.  It  contains  all  of  the  same  information  found  in  the  Lookup  Details  Page,  but 
with  text  boxes  available  to  submit  updates.  The  Social  Security  Number  (SSN)  field  is 
not  updateable  because  that  is  the  unique  identifier,  or  primary  key,  of  the  database.  If 
the  SSN  number  is  changed  the  record  is  essentially  deleted. 
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Add  new  Personnel  Record 

Rank  Rate  First  Name*  ME  Last  Name*  SSN* 


Work  Information 


Job  Title 
Department* 
Work  Phone* 
E-Mail 


■■■■■ 

me@esu.alameda.cg 


Horne  Information 


Address: 


Street 

City,  State,  Zip 
Home  Phone* 
Beeper# 


Intranet  Username*  (user 

Intranet  Password*  **** 

Confirm  Password*  [**** 

*  required  fields 

Add  New  Personnel  I  Reset 


Figure  8.8  Add  New  Personnel  On-line  Form 
e.  Add  New  Personnel  On-line  Form:  This  page  is  the  form  used  to  enter  new 
personnel  into  the  database.  An  Intranet  username  and  password  may  also  be  assigned  at 
this  time.  The  default  security  access  level  on  a  new  username  is  "user". 
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Electronic  Support  Unit  Alameda  Intranet 


Successful  Update  to  Personnel  Details 


LT  Todd  Hannah 


Work  Information 


.Job  Title 
Department 
Work  Phone 
E-Mail 


Horne  Information 


Address: 


SSN:  544699911 


Home  Phone 
Beeper#,  Cell  Phone  •  ■  5675678; 


Administrative 


Intranet  Application  Designer 
Detachment  San  Pedro 
()  1234567  ext: 
thehannahs@thegrid.net 

459  Chips  Way 
Monterey  CA93955-5000 
(408)6580989 


Figure  8.9  Successful  Update  to  Database 
f.  Successful  Update  to  Database:  This  page  confirms  that  data  was 
successfully  entered  into  the  database.  A  similar  page  is  displayed  after  every  successful 
submission  of  data  to  the  Intranet  databases. 
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;  /A  Deletion  is  a  permanent  action. 


to  inform  them  when  a  record  has  been  deleted, 

r  ■  v  v'.V:  :  ..  .  V  ^  \  •  !  ;  K 


Figure  8.10  Warning  Box  for  Deleting  Records 


ENS  Joe  George 


Work  Information 


Job  Title 
Department 
Work  Phone 
E-Mail 


I  Home  Information 


Address"  99  Broadway 

’  : ;  New  York  CA 10004 

Home  Phone  (408)  9999999 

Beeper  #;  Cell  Phone  ; 


COTR  Branch 
0  1234567  ext: 
thehannahs@thegrid.net 


Leave  Requested 


Cancel 


Figure  8.11  Delete  a  Record 

g.  Delete  Records:  Deleting  information  is  handled  with  caution  throughout  the 
Intranet.  First,  the  user  must  be  logged  in  at  an  appropriate  security  access  level.  In  the 
Personnel  Application,  the  user  must  be  logged  in  at  security  access  level  "sec  admin"  to 
even  get  to  this  page.  When  this  page  is  called,  a  Warning  Box  (Figure  8.10)  is 


immediately  displayed.  The  user  must  click  "OK"  to  continue.  In  order  to  perform  a 
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deletion,  the  user  must  click  on  a  large  red  button.  Email  is  automatically  forwarded  to 
the  record's  owner  informing  them  of  the  deletion. 
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E. 


LEAVE  APPLICATION 


1.  Introduction 

The  purpose  of  the  Leave  Application  is  to  provide  better  tracking  of  personnel 
for  the  ESU  Command  and  its  members.  This  application  addresses  one  of  the 
Command's  top  goals  as  identified  during  the  Analysis  Phase.  Users  who  have  logged  in 
at  security  access  level  "user"  have  full  access  to  the  Leave  Application.  Full  access 
allows  users  to  view,  add,  update  and  delete  records. 


Figure  8.12  Leave  Admin  Application  Navigation  Structure 


2.  Web  Pages  of  the  Leave  Application 

a.  List  of  Web  Page  Figures:  The  following  table  lists  the  names  of  the  Web 


pages  of  this  application  and  the  corresponding  figure  numbers. 


Web  Page 

Figure 

Home  Page  (with  Leave  Application  highlighted) 

8.14 

On-line  Leave  Request  Form 

8.15 

Leave  Approval  Chain 

8.16 

Status  of  Pending  Leave  Requests 

8.17 

Summary  of  Leave  Information 

8.18 

Details  of  a  Leave  Request 

8.19 

Past  Leave  Archive 

Figure  8.13  Table  of  Web  Pages  and  Corresponding  Figures 
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Home  Page 

SlU-Map 


Electronic  Support  Unit  Alameda  Intranet 


Online  Leave  Request  Form 


Name:  [Doolittle,  Doctor  (LT) 

Leave  Address:  m — : - TT - 

sSe'et  *  "  "  [Mayheart  Lane 

City-State,  Zip  *  [Monterey 

Leave  Phone  * 


Begirt  Leave  *  (aWdc^)  1  may  1998 
End  Leave  *  |l5  may  1998 

Number  o  f  Days  on  T7Z — “• 

T.pwp  I™.: 1  ' 


^My  e-mail  adless  is:  *  {thehanhahs@thegrid.net 
First  Approval  (  dARDIS,  DEAN  (LT)  § 

Second  Approval  j  Hannah,  Todd  (LT)  HI 

Final  Approval 


♦Required  Fields 

When  this  form  is  submitted,  an  email  notification  of  your  leave  request  will  be  sent  along  the  approval 
chain  of  command  ’ 

Can't  find  your  record!?  Click  Here  to  Add  New  personnel  to  the  database. 


Currently  ah  Lcawa  Pmdino  fcaavaTteotjes 
.  :  .  (restrictBql  access); 


Figure  8.15  On-line  Leave  Request  Form 
c.  On-line  Form  Leave  Request:  This  page  is  a  form  for  a  user  to  request  leave. 


The  information  is  entered  into  the  database  for  action. 


86 


Electronic  Support  Unit  Alameda  Intranet 


Review  Pending  Leave  Requests 

Only  make  a  selection  in  the  block  that  yon  are  Approval  Authority  for.  Each  person  in  the  approval  chain  will  review 
these  requests  and  elide  the  Submit  button  for  each  individual  request  that  is  reviewed,  This  is  like  a  signature  so  don’t  “sign*  someone 
elses  name  in  another  block,  (i.  e.  <>ily  seled  Subinit  in  the  Einal^^oval  blodc  if  youare  the  Final  Approval  Authority). 


|  Name  j 

1  When 

1  NVhy 

Immediate 
Supervisor  J 

j  Department  Head  j 

j  Final  Approval 

ETC  McClain 

4/6/98 

To  visit  mom. 

ETC  Hamlin 

LTDARDXS 

LCDR 

Hernandez 

thru  4/1 5/98  for?  days  leave. 

approved 

approved 

NotYet 

Reviewed 

Click  here  to  view  more  details 
about  lias  Leave  Request 

.  r  Approved 
c  Disapproved 

[Submit/) 

r  Approved 
r  Disapproved 

Submit  j 

j~<r}  Approved 
r  Disproved 

rSubrhitj 

|  Name  j 

|  When 

why 

Immediate 

Supervisor 

|  Department  Head  | 

|  Final  Approval 

TT2  Rauschkolb 

4/6/98 

To  vacation  withrry 

ETC Hamlin 

LT  Keyes 

LCDR 

thru  5/1/98  for  24  days  leave. 


NotYet 

Reviewed 


Not  Yet  Reviewed 


CSck  here  to  view  more  details 
ahmiirihk  Leave  Request 


C  Approved  c  Approved 
r  Disapproved  c  Disapproved 


NotYet 

Reviewed 

C  Approved 
r  Disapproved 

Submit] 


:  .  Leave  / "p^tUssJS: Mg . Oofar'^  R^j.fga 

g  ...  ,  , -  :  v  ^B8SWfiSKt^WBCt«08SS).  .  #  -.-i'  tvS  ~  ~  *  -  »*■*-  -  *  -  - 


Figure  8.16  Leave  Approval  Chain 


d.  Leave  Approval  Chain:  Supervisors  may  review,  approve,  or  deny  on-line 
leave  requests  in  this  area.  The  page  is  restricted  to  supervisors  by  security  level. 
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|lpS! 

Electronic  Support  Unit  Alameda  Intranet 

'Mk: 

Status  of  Pending  Leave  Requests 

Not  Yet  Reviewed  Leave  Requests 

[Name 

Leave  Period  and  Immediate  Supervisor: 

Department  Head: 

Final  Approval: 

Duration  Status 

Status 

Status 

Reagen,  Danielle 

4/8/98  thru  4/1 0/98  for  LTJG  Rausch 

LTBenhart 

LCDR  Hernandez 

details 

(AEC) 

2  days  leave. 

APPROVE 

Approved  L< 

Not  Yet  Reviewed  Not  Yet  Reviewed  Not  Yet  Reviewed 

jave  Requests 

delete 

■  Name 

Leave  Period  and  Immediate  Supervisor: 

Department  Head: 

Final  Approval: 

Duration  Status 

Status 

Status 

Doolittle,  Doctor  CLT)  5/1/98  thru  5/15/93  for  LT  Fife 

LTBenhart 

LCDR  Hernandez 

details 

15  days  leave: 

APPROVE 

approved 

approved 

approved 

delete. 

McClain,  Chuck  (ETC)  4/6/98  thru  4/15/98  for  ETC  Hamlin 

LTDARDIS 

LCDR  Hernandez 

details 

7  days  leave. 

APPROVE 

approved 

approved 

approved 

delete 

Rauschkolb,  Mark 

4/6/98  thru  5/1/98  for  ETC  Hamlin 

LT.Keyes 

LCDR  Hernandez 

details 

(TT2) 

24  days  leave. 

APPROVE 

Disapprovee 

Not  Yet  Reviewed 

Leave  Requests 

Not  Yet  Reviewed 

approved 

.  delete 

[Name 

Leave  Period  and  Immediate  Supervisor: 

Department  Head: 

Final  Approval: 

Duration  Status 

Status 

Status 

Seagar,Bob  (AD2) 

4/7/98  thru  5/1/98  for  ETC  Hamlin 

LT  Keyes 

LCDR  Hernandez 

details 

23  days  leave. 

APPROVE 

disapproved 

disapproved 

disapproved 

delete 

:~p 


Past  Leave  Archive  r-Ohlmp  Leave  Rccn^cst  Form 


Figure  8.17  Status  of  all  Pending  Leave  Requests 
e.  Status  of  Pending  Leave  Requests:  This  page  contains  the  current  approval 
status  of  all  leave  requests  entered  in  the  database. 
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Electronic  Support  Unit  Alameda  Intranet 


Summary  of  Personnel  Leave  Information 

Currently  on  Leave  (approved) 


McClain,  Chuck  (ETC) 
Rauschkolb,  Mark  CIT2) 


Leave  Period  and  Duration 


4/6/98  thru  4/15/98  for  7  days  leave;. 
4/6/98  thru  5/1/98  for  24  days  leave. 


details  delete 
details  delete 


Requested  Current  Leave  (not  yet  reviewed  or  denied) 


Leave  Period  and  Duration 


Planning  to  Begin  Leave  within  the  Next  30  Days 


Leave  Period  and  Duration 


Doolittle,  Doctor  (LT) 
Seagar,  Bob(AD2) 


5/1/98  thru  5/15/98  for  15  days  leave 
4/7/98  thru  5/1/98  for  23  days  leave. 


details  APPROVE  delete 
details  APPROVE  delete 


Planning  to  Begin  Leave  Over  30  Days  from  Today 


Leave  Period  and  Duration 


Figure  8.18  Summary  of  Current  and  Upcoming  Leave 
f.  Summary  of  Leave  Information:  Users  may  check  up  on  the  status  of  their 
own  leave  requests  or  see  others  at  this  page.  The  application  displays  who  is  currently 


on  leave,  who  will  be  on  leave  and  contains  an  archive  of  who  was  on  leave.  Users  may 
also  follow  links  to  view,  edit  or  delete  details  of  their  requests  from  here. 
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Details  of  lt  Doolittle's  Leave  Request 
LT  Doctor  Doolittle 


Leave  Address: 


Street 

City,  State 

Leave  Phone 

Mayberry Lane 
Monterey 

,CA 

(888)  888-8889 

Begin  Leave 

Bid  Leave  . 

Number  of  Days  on  Leave 
Reason  for  Request 

5/1/98 

5/15/98 

15 

To  tend  the  sheep 

e-mail  address*? : 

■  thehannahs@thegrid.n' 

et  Approval  Status 

First  Approval 

LTFife 

approved 

Second  Approval 

LTBenhart 

approved 

Final  Approval  Aiithority 

LCDR  Hernandez 

approved 

Sfe  ^States  of  /M  Fentfeig  te 


Cunreatly  op  Leave 

. (restricted  access)  Leave, Request 


Past  Leavg  Archive 


Figure  8.19  Details  of  a  Leave  Request 
g.  Details  of  a  Leave  Request:  This  page  displays  the  details  of  a  leave  request 
in  the  database. 
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One  Year  Leave  Archive  by  Last  Name  (View  by  Date) 


I  Name 

Duration 

Began  Leave 

Leave  Ended 

Benhart,  Ralph  (LT) 

1  days 

1/1/98 

1/2/98 

McClain,  Chuck  (ETC) 

7  days 

4/6/98 

4/15/98 

Reagen,  Danielle  (AEC) 

2  days 

4/8/98 

4/10/98 

Seagar,  Bob  (AD2) 

23  days 

4/7/98 

5/1/98 

Weeks,  Steven  (ETC) 

7  days 

3/28/98 

4/5/98 

Back  to  top 


One  Year  Leave  Archive  by  Date  (View  by  Person) 


(Leave  Ended 

Began  Leave 

Duration 

Name 

5/1/98 

4/7/98 

23  days 

Seagar,  Bob  (AD2) 

4/15/98 

4/6/98 

7  days 

McClain,  Chuck  (ETC) 

4/10/98 

4/8/98 

2  days 

Reagen,  Danielle  (AEC) 

4/5/98 

3/28/98 

7  days 

Weeks,  Steven  (ETC) 

1/2/98 

1/1/98 

1  days 

Benhart,  Ralph  (LT) 

Back  to  top 


Figure  8.20  Past  Leave  Archive 

h.  Past  Leave  Archive:  This  page  displays  the  names  of  all  personnel  who  have 
taken  leave  over  the  past  year.  The  archive  is  sorted  both  by  name  and  by  date.  A  similar 
archive  page  is  used  for  the  TAD  Application,  the  Announcements  Application,  and  the 


Supply  Application, 
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F. 


TAD  APPLICATION 


1.  Introduction 

The  purpose  of  the  TAD  Application  is  to  provide  better  tracking  of  personnel  for 
the  ESU  Command  and  its  members.  This  application  addresses  one  of  the  Command's 
top  goals  as  identified  during  the  Analysis  Phase.  Users  who  have  logged  in  at  security 
access  level  "user"  have  full  access  to  the  TAD  Application.  Full  access  allows  users  to 
view,  add,  update  and  delete  records. 


Figure  8.21  TAD  Application  Navigation  Structure 


2.  Web  Pages  of  the  TAD  Application 

a.  List  of  Web  Page  Figures:  The  following  table  lists  the  names  of  the  Web 
pages  of  this  application  and  the  corresponding  figure  numbers.  Some  pages,  which  were 
included  as  parts  of  the  Leave  Application,  are  nearly  identical  in  the  TAD  Application. 
Screen  shots  of  these  pages,  such  as  the  Past  TAD  Archive  page,  are  not  shown. 


Web  Page 

Figure 

Home  Page  (with  TAD  Application  highlighted) 

8.23 

On-line  TAD  Notification  Form 

8.24 

Summary  of  TAD  Information 

8.25 

Figure  8.22  Table  of  Web  Pages  and  Corresponding  Figures 
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Welcome  admin .  You  are  logged  in  with  security  level  admin 
General  Announcements  Personnel  on  Leave  Today 


(Announcement 


Posted  by  |Name 


Leave  Period  ends  on: 


!  Picnic  Today)  1400  details 


Benhart,  Doolittle,  Doctor  (LT)  5/15/98  after  15  days. 
Ralph  CLD, 

i;  5/4/98  T^Siimmsre 


Post-a  New  Announcement 


Security 


Personnel  TAD  Today 


Intranet  Login 

for  HSU  Yon  MUST  ] 

login  to  i 

S9HI 

IPf 

Ml 

lllljll 

~ /; \ •  -l' ,v xi- 

m  s  m ail 


tad  Where 

until 


Byrd,  Scott  (TC2)  5/1 0/98  USCGC  RELIABLE 
Fife,  Barney  (LT)  5/1 0/98  USCGC  Bittersweet 


Figure  8.23  Home  Page  with  TAD  Application  Highlighted 
b.  Home  Page  with  TAD  Application  Highlighted:  The  Leave  Application  is 
highlighted  here  on  the  Home  Page.  It  shows  the  user  which  personnel  who  are  away  on 


leave  for  the  day. 
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Online  Temporaiy  Assigned  Duty  (TAD)  Notification  Foim 


If  you  are  going  to  be  TAD,  please  fill  out  this  form. 


Who 

Fife,  Barney  (LT) 

Il)' 

Leaving 

5/4/98  ! 

Returning  ]5/10  ! 

Where:  |lJSCGC  Bittersweet 

(Command 

Name) 


Reason 
for  TAD 

To  fix  the  radar. 

“1 

grj 

6"  Submit  TAD  Form".  1  RjjdBfcj  . . 

Can't  find  your  record?  Click  Here  to  Add  New  personnel  to  the  database. 

•  Current  and  UocominsTAD  "  TAD  Notification  Form  Past  TAD  Arctwe 

Figure  8.24  On-line  TAD  Notification  Form 

c.  On-line  TAD  Notification  Form:  This  page  is  a  form  for  a  user  to  notify  the 
Command  that  they  will  be  away  TAD.  The  information  is  entered  into  the  database. 
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MS?  Electronic  Support  Unit  Alameda  Intranet 


Summary  of  TAD  Information 

Currently  TAB 


Name  TAD  Period  Where _ Reason 


Byrd,  Scott  (TC2)  4/6/98  thru  5/1 0/98  USCGC  RELIABLE  Fix  the  radar  details  delete 

Fife,  Barney  (LT)  5/4/98  thru  5/1 0/98  USCGC  Bittersweet  To  fix  the  radar.  details  delete 


Planning  to  Begin  TAB  within  the  Next  30  Bays 


Name  TAD  Period  Where _ Reason 


Planning  to  Begin  TAB  Over  30  Bays  from  Today 


TAD  Period 


Where 


Wallace,  Tony 
(GS9) 


6/8/98  thru  6/1 0/98  NPS 


Reason 


2  day  seminar  on 
Intranets 


details  delete 


'S 


IS-  Past  TAD  Art&ge 


Figure  8.25  Summary  of  TAD  Information 
d.  Summary  of  TAD  Information:  The  application  displays  lists  of  personnel 
who  are  currently  TAD  and  who  will  be  TAD  in  the  future.  Users  may  also  follow  links 
to  view,  edit  or  delete  details  of  their  notifications  from  here. 
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G.  ANNOUNCEMENTS  APPLICATION 


1.  Introduction 


The  purpose  of  the  Announcements  Application  is  to  provide  better 
communications  throughout  the  ESU.  It  also  empowers  employees  to  make  broadcast 
announcements  instantly. 


Figure  8.26  Announcement  Application  Navigation  Structure 


2.  Web  Pages  of  the  Announcements  Application 

a.  List  of  Web  Page  Figures:  The  following  table  lists  the  names  of  the  Web 
pages  of  this  application  and  the  corresponding  figure  numbers.  The  application  also  has 
pages  for  updating  announcements,  deleting  announcements  and  viewing  a  past 
announcement  archive.  Screenshots  of  these  pages  are  not  provided  because  they  are 
similar  to  the  ones  from  other  applications. 


Web  Page 

Figure 

Home  Page  (with  Announcements  Application  highlighted) 

8.28 

Announcements  Details 

8.29 

On-line  Announcement  Form 

8.30 

Figure  8.27  Table  of  Web  Pages  and  Corresponding  Figures 
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Electronic  Support  Unit  Alameda  Intranet 


Welcome  admin . 
General  Announcements 


You  are  logged  in  with  security  level  admin 

Personnel  on  Leave  Today 


..Ml 


Announcement 


Picnic  Today!  1400  details 


Posted  by 


Benhart, 
Ralph  (LT) , 
5/4/98 


Post  a  New  Announcement 


Security 


*t§lB 


Leave  Period  ends  on: 


Leave  Summary 


Personnel  TAD  Today 


Byrd,  Scott  (TC2)  5/1 0/98  USCGC  RELIABLE 

,  .  -  -.•=  ’  .  "  ■  ^  /  ~  B  ;  "•  ■■■"■ 

.  ■' :  T&r>  Summer 


i  B:  B::.::,:/: bBLBBBBLbCBBB  BBB  .  B' 

.  .  •  ■ 


Figure  8.28  Home  Page  with  Announcements  Application  Highlighted 
b.  Home  Page  with  Announcements  Application  Highlighted:  The 


Announcements  Application  is  highlighted  here  on  the  Home  Page.  This  is  where  the 
announcement  headline  is  broadcast.  A  person  follows  the  link  for  more  details  of  an 


announcement. 
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Electronic  Support  Unit  Alameda  Intranet 


Announcement  Details 


Details  of  that  announcement  are  as  follows: 

Headline:  Picnic  Today!  1400 

Details:  The  ESU  Picnic  will  be  held  on  the  front  lawn  at  1300.  Volleyball  net  will  be 

available. 

Posted  on:  5/4/98 

Post  expires:  5/5/98 

Point  of  Contact:  Benhart,  Ralph  (LT) 


Post  a  New  Announcement  View  Past  Announcement  Archive  Delete  this  Announcement 


Figure  8.29  Announcement  Details 


c.  Announcement  Details:  This  page  contains  further  details  of  the 


announcement  headline  posted  on  the  Home  Page. 
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Add  a  new  Announcement  to  the  Home  Page 

These  announcements  are  for  general  all-hands  broadcast  and  will  be  visible  to  ANYONE  visiting  the  ESU 
Alameda  Home  Page.  Bear  this  in  mind  when  making  a  post  and  keep  it  professional.  Any  validated  ESU 
Alameda  Intranet  user  may  post  announcements. 


Point  of  Contact  |Benhart,  Ralph  (LT)  Jrj 

Date  of  post  5/4/98 

Date  post  expires  and  removed  from  (5/5/98 
HomePage 

Announcement  Headline  for  Home  picnic  Today!  1400 

Page:  ■  ••••  .  . '  - 

(Please  limit  to  one  or  two  lines  without  carnage  ■ — — — - — - - - - — - 

returns.) 

Details  of  Announcement:  (The  ESU  Picnic  will  be  held  on  the 

(Only  headline  visible  on  Home  Page.  Details  \  front  lawn  at  1300.  Volleyball  net 
upon  following hyperlmk.  No  carnage  returns.)  wm  be  available. 


Volleyball  net 


Post  Announcement  to  ESU  Alameda  Home  Page 


sMWiewPast  Announcement  Archive 


Figure  8.30  On-line  Announcement  Form 
d.  On-line  Announcement  Form:  This  form  is  used  to  post  an  on-line 
announcement.  Anyone  in  the  Command  who  has  logged  on  to  the  Intranet  is  able  to 
broadcast  an  announcement  using  this  form. 
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H.  PERSONNEL  REPORTS  APPLICATION 


1.  Introduction 


The  purpose  of  the  Personnel  Reports  Application  is  to  provide  better 


communications  throughout  the  ESU.  It  contains  reports  for  information  the  ESU 


Command  considers  vital. 


Figure  8.31  Personnel  Reports  Application  Navigation  Structure 


2.  Web  Pages  of  the  Personnel  Reports  Application 

a.  List  of  Web  Page  Figures:  The  following  table  lists  the  names  of  the  Web 
pages  of  this  application  and  the  corresponding  figure  numbers. 


Web  Page 

Figure 

Recall  Log 

8.33 

Department  Phonebook 

8.34 

Alphabetical  Phonebook 

8.35 

Marks  Due  this  Month 

8.36 

Status  of  all  Marks  Due 

8.37 

Complete  Marks  Schedule 

8.38 

Edit  Marks  Schedule 

8.39 

Figure  8.32  Table  of  Web  Pages  and  Corresponding  Figures 
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Recall  Log 


Work  Phone  &  E-Mail  Listings  -  Alphabetical 


Recall  Log  is  FOR  OFFICIAL  USE  ONLY 


Name  Address  _  Home  Phone#  Beeper# 


Baker,  Jeff  (ETl)  Mulberry  Way,  Alameda(CA)  (408)8768768 

Bartlett,  Rex  (ETC)  Friar  Tuck  Lane,  Alameda  (CA)  (408)  980909 

Benhart, Ralph (LT)  3568B  JurrasicPark Ave., Monterey(CA)  ()6588958 

Bennett,  Darvin  (SK.C)  Stourport  Av,  Alameda(CA)  (408)  87 687 68 

Brewster,  Punkies  (AM2)  20Punkyway,  Seaside(CA)  0  3938444  546654564 

Byrd,  Scott  (TC2)  ,  (CA)  (408) 

Cantu,  Edward  (IT3)  thers,  (CA)  (408) 

Clarke,  Brian  (TCCS)  ,  (CA)  (408) 

DAKDIS,  DEAN  (LT)  222  RAMAGENDR,  GULAGULA(CA)  (408)3932563 

Doolittle,  Doctor  (LT)  Animal  Way,  Pacific  Grove(CA)  (408)6582074 

Figure  8.33  Recall  Log 

b.  Recall  Log:  The  Recall  Log  is  used  to  display  the  home  addresses  and  phone 
numbers  of  ESU  personnel.  Its  primary  purpose  is,  in  case  of  a  general  recall,  for  the 


duty  officers  to  be  able  to  locate  personnel  who  are  off  duty. 
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Phone  &  E-Mail  Listings  -  by  Department 


Click  Here  for  Phone  &  E-Mail  Listings  -  listed  Alphabetically 


;  ;:  S 


■Commanding  Officer:  work  Phone# 


Lane,  Ed  (CDR) 


[Executive  Officer: 


(510)437-3923: 


Hernandez,  Mark (LCDR)  (5ip>437-3?2i 
Electronic  Systems  Branch 


email 


I  Name 


DARDIS,  DEAN  (LI) 
Jackson,  Carol  (ASM3) 
Joes,  Stalin  (CDR) 

Olsen,  Chris  (CW02) 

Rausch,  Nathan  (LTJG) 
Reagen,  Danielle  (AEC) 
Reichert,  Tracy  (ET2) 
Smith,  Malcom  (LTJG) 
Stokes,  John  (LT) 

Wei  den,  John  (CW04) 

Back  to  Toy 

IRM  Branch 


Job  Title 


Work  Phone  # 


DEANER  OF  WINNERS 
Dictator 

Vessels  Section  (WHEC,  WMEC, 
WLB) 

Elec  Sys  Branch  Chief 

Pipeliner  Superviser  /  DGPS 

Kodiak  IRM  Branch  Chief 
Shore  Section  (WPB) 


(408)  393-1404: 

0 1234567: 
(408)79698  :  8970 

(510)437-3913: 

(510)437-5351: 

01234567: 

(510)437-5894: 

01234567: 

(408)  1211234: 
(510)437-3795: 


■  Name 


Byrd,  Scott  (TC2) 
Cantu,  Edward  (TT3) 
Clarice,  Brian  (TCCS) 
Enberg,  Melvin  CTC1) 

.  Fontaine  ..Trp.unr.fTn'i  . 


Job  Title 


RSM 

TTShop 

Dll  Frequency  Manager 
RSM 


Work  Phone  # 


(707)  839-6109 
(510)437-3290 
(510)437-5305 
(415)399-3405 
_« lift  437-37.90 


email 


thehannahs@thegrid.r 

thehannahs@thegrid.i 

thehannahs@thegridr 

thehannahs@thegrid.f 

-  thp.h  annabstffrthp  oriHr 


Figure  8.34  Department  Phonebook 


c.  Department  Phonebook:  This  phonebook  is  organized  by  department.  If  the 
departments  change,  the  phonebook  structure  will  change  dynamically.  For  example, 
users  may  add  new  departments  to  the  database  and  the  phonebook  will  update  itself 
automatically.  It  doesn’t  need  to  be  redesigned. 


A 


Name  Job  Title _ Department _  Work  Phone  #  email 


Back  to  Top 


B 


Name  Job  Title  _ Depaitment _ Work  Phone  #  pmail 


Baker,  Jeff  (ET1) 

Bartlett,  Rex  (ETC) 
Benhart,  Ralph  (LI) 
Bennett,  Damn  (SKC) 
Brewster,  Punkies  (AM2) 
Byrd,  Scott  CTC2) 

Back  to  Top 

C 


Name  Job  Title  _ Department  Work  Phone  #  email 


Cantu,  Edward  (TO)  TTShop  IRM  Branch  (510)437-3290:  theharmahs@thegndTiet 

Clarice,  Brian  (TCCS)  D1 1  Frequency  Manager  IRMBranch  (510)437-5305:  thehannahs@thegnd_^et 

Back  to  Top 


TTShop 

Alt-COTR 

Network  Engineer  PCS 
Storekeeper 
Tech  Support 
RSM 


ESU  Business  Services 
Branch 
COIR.  Branch 
Detachment  Oxnard 
Business  Services  Branch 
Detachment  San  Pedro 
IRMBranch 


(510)437-5668: 

(510)437-3874:9999 
0  1234567: 
(510)437-5301: 
(515)1234567: 

(707)  839-6109: 


theharmahs@thegrid.net 

thehannahs@thegrid.net 

theharmahs@thegrid.net 

thehannahs@thegridnet 

theharmahs@thegrid.net 

thehannahs@thearid.net 


Figure  8.35  Alphabetical  Phonebook 


d.  Alphabetical  Phonebook:  This  phonebook  is  arranged  alphabetically  by  last 


name. 


Electronic  Support  Unit  Alameda  Intranet 


Marks  Due  this  Month 


■  Rank/  Name 
(Rate 

Marks  Due  by 

Current  Status 

l>?-5 

CW02  Hannah,  Leesa 

6/1/98 

finished 

Finished 

Not  Finished 

AEC  Reagen,  Danielle 

6/1/98 

Not  Finished 

Finished 

Not  Finished 

TCCS  Clarke,  Brian 

6/1/98 

Not  Finished 

Finished 

Not  Finished 

ATC  Robertson,  Jill 

6/1/98 

Nat  Finished 

Finished 

Not  Finished 


XO  to  Update  Status 
(For  XO’s  nse  only!) 

r 


Marks  Due  Next  Month 


Rank /Rate  Name  Marks  Due 


AE1  Louie,  Baby  .  7/1/98 

AMI  Johns,  Sherri  7/1/98 


r,  ..  . . .  . X.X..  -.v--...- . ;p-  • . .  p*..  . .  ........  .  ,  - - - ...v™  - - - - ....... 

;  Complete  Marks  Status  Page  Marks  Due  .  -  Complete  OER/Marks  Schedule 


Figure  8.36  Marks  Due  this  Month 

e.  Marks  Due  this  Month:  This  page  is  primarily  for  the  Executive  Officer's 
benefit.  It  provides  the  XO  with  the  ability  to  quickly  determine  whose  marks  must  be 
completed  and  when.  It  allows  him  to  update  the  status  of  when  the  marks  were  last 
completed.  This  application  addresses  one  of  the  XO's  top  goals  as  determined  during  the 
analysis  phase. 
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Electronic  Support  Unit  Alameda  Intranet 


Status  of  Marks 


I  Name 

Marks  Status 

Ul  X 

XO 

Farms,  Toad  (LTJG) 

Farms,  dfgh  (LTJG) 

■ 

Farms,  653456  (LTJG) 

Joes,  Stalin  (CDR) 

DARDIS,  DEAN  (LT) 

finished 

3/26/98 

Lane,  Ed  (CDR) 

finished 

3/26/98 

Welden,  John  (CW04) 

finished 

3/26/98 

George,  Joe  (ENS) 

finished 

4/1/98 

Hannah,  Leesa  (CW02) 

finished 

5/4/98 

Baker,  Jeff  0 

Not  Finished 

Bartlett,  Rex  (ETC) 

Not  Finished 

Figure  8.37  Status  of  All  Marks  Due 


f.  Status  of  all  Marks  Due:  This  page  displays  the  status  of  everyone's  marks.  It 


also  indicates  the  date  when  the  last  update  occurred. 
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Enlisted  Marks  and  OERs  Schedule  by  Date  Due 

(view  by  Rank/Rate) 

|Rate/Rank 

Marks  are  Due  by 

Seaman  (E2) 

1/1/98 

edit 

Seaman  (El) 

2/1/98 

edit 

LTJG  (02) 

2/1/98 

edit 

LCDR  (04) 

3/1/98 

edit 

LT  (03) 

3/14/98 

edit 

CDR  (05) 

4/1/98 

edit 

CW04  (CW04) 

4/1/98 

edit 

Seaman  (E3) 

5/1798 

edit 

ENS  (01) 

5/1/98 

edit 

CWOS  (CW03) 

5/1/98 

edit 

CAPT  (06) 

5/10/98 

edit 

Chief  Petty  Officer  (E7) 

6/1/98 

edit 

CW02  (CW02) 

6/1/98 

edit 

First  Class  Petty  Officer  (E6) 

7/1/98 

edit 

CWOl  (CW01) 

7/15/98 

edit 

Second  Class  Petty  Officer  (E5) 

10/1/98 

edit 

Third  Class  Petty  Officer  (E4) 

11/1/98 

Back  to  Top 


Enlisted  Marks  and  OERs  Schedule  by  Rank/Rate  (view  by  Date  Due) 


Figure  8.38  Complete  Marks  Schedule 


g.  Complete  Marks  Schedule:  This  page  displays  the  dates  when  a  particular 


rank  or  rate's  marks  are  due.  LTJG  marks,  for  example,  are  due  by  February  1st  according 
to  this  schedule. 
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Hill 


Figure  8.39  Edit  Marks  Schedule 

h.  Edit  Marks  Schedule:  The  schedule  of  when  marks  are  due  can  be  edited 
using  this  form.  Sometimes  the  Coast  Guard  will  make  changes  to  the  marks  schedule. 
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I. 


SUPPLY  APPLICATION 


1.  Introduction 

The  purpose  of  the  Supply  Application  is  to  improve  the  supply  ordering  and  parts 
tracking  process.  Users  may  submit  on-line  Purchase  Requests  (PRs),  follow  up  on  the 
status  of  their  orders,  and  view  a  past  order  archive  with  this  application. 

The  Supply  Application  radically  redefines  work  roles  by  pushing  responsibility 
for  Purchase  Request  status  updates  back  down  to  the  individual  who  submitted  the  order. 
This  design  addresses  one  of  the  Commands  top  goals,  to  liberate  the  Storekeeper  of  the 
tedious  and  mundane  task  of  checking  up  on  everyone  else's  PRs. 


Figure  8.40  Supply  Application  Navigation  Structure 
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2.  Web  Pages  of  the  Supply  Application 


a.  List  of  Web  Page  Figures:  The  following  table  lists  the  names  of  the  Web 
pages  of  this  application  and  the  corresponding  figure  numbers. 


Web  Page 

Figure 

Supply  Database  Home  Page 

8.42 

On-line  Purchase  Request  Form  -  Part  1 

8.43 

On-line  Purchase  Request  Form  -  Part  2 

8.44 

Complete  Purchase  Request 

8.45 

Warning  Box  about  Assigning  PR  Numbers 

8.46 

Storekeeper  Form  to  Assign  PR  Number 

8.47 

Status  Log  Update  Form 

8.48 

Order  Marked  as  Received 

8.49 

Figure  8.41  Table  of  Web  Pages  and  Corresponding  Figures 
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Supply  Web  Database  Application 

CT  out  a  New  Purchase  Request  Past  Purchase  Request  Archive 

Storekeeper^  To  Do  List:  Outstanding  PR's  without  assigned  PR  numbers 


Date  PR  Submitted  Department/Branch 


5/4/98 


Back  to  Top 


COTR  Branch 


Name  of  Person  to  Contact 


ETC  Chuck  McClain  (562)  732-7271, 
Location:  ESU  Det  San  Pedro 


Assign  PR  number  etc. 


details  Assign  PR# 


Crewmember’s  To  Do  List:  Outstanding  orders  are  listed  by  department.  Individuals  who  submit  PRs  are  required  to 
periodically  review  their  order(s)  here  and  update  the  status  by  following  link  to  the  PR  status  log.. 


Efertrosic  Systems  Brash  ! 


&n.fodn?: 


Electronic  Systems  Branch 


Click  for  Details  Received  or  Delete 

LT  Todd  Hannah  Q  1234567;  Location: 

123123 

5/4/98 

*  PR  details  *  Order  Received 

♦View  Status  Log  *  Delete  PR  : 

*  Update  Status  Log 

Back  to  Top 

Click  ibr  Details  Receive  d  at  D  elete 

GS7  Brenda  Rios  (5 1 0)  437-5784;  Location:  ESU 
Alameda 

1231234 

4/7/98 

*  PR  details  *  Order  Received 

♦.View  Status  Log  '  *  Delete- ‘ 

*  Update  Status  Log 


Figure  8.42  Supply  Database  Home  Page 
b.  Supply  Database  Home  Page:  The  Supply  Database  Home  Page  presents  the 
user  with  a  list  of  all  outstanding  Purchase  Requests  (PR)  at  the  ESU.  There  is  a  "To  Do" 
list  for  the  Storekeeper  which  shows  all  PRs  that  have  been  submitted  but  have  not  yet 
been  assigned  a  PR  Number.  The  remainder  of  the  page  contains  ESU  personnel  "To 
Do"  lists,  organized  by  department.  Each  person  who  has  submitted  a  PR  is  required  to 
periodically  check  on  the  status  of  the  request,  with  the  supply  vendor,  and  update  a 
status  log.  Previously,  this  information  was  not  available  to  all  employees  and  the 
Storekeeper  had  to  individually  check  up  on  the  status  of  each  outstanding  PR. 
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Step  1:  Fill  out  the  following  initial,  data  for  the  PR. 


ROCUREMENT  EuUEST 

ROCESS  I  APIDLY 


T  Name,  Phene  Number  and  Branch  of  Persorito  Contact 
|  LJ  Todd  Hannah  (  )  12^567;  Location: 

Branch:  (Electronic  Systems  Branch  lil 

Location:  |e$U  Alameda  PI 

2.  Type  of  Request 
New  Request  l* 

4.  Additional  Information  (Suggested  supply  sources,  etc.) 
Name:  |joes  Hardware 


Downtown 


(Monterey 


5.  ^iprowng  Offials  : 

Approving  Officials 
(A) 

(1)  Authorized  Requisitioner  Name 

Name:  |  CDR  Ed  Lane  ^ 

(2)  Accounting  Certification  Officer 

Name:  | SKC  Darvm  Bennett W 1 

(3)  Supervisor 

Name:  |l_T  Barney  Fife  3 

(4)  Requester 

Name:  |  LT  Todd  Hannah  W\ 


Routing  Symbol 

(B) 


(Storekeeper 


(Electronic  Systems  Branch 


|  Electronic  Systems  Branch 


6.  Consignee  and  Destination 


....  -  >: 


COMMANDING  OFFICER,  ESU  ALAMEDA 


BLDG  21  RM128  COAST  GUARD  ISLAND 


?.  Date  Required  j 

8.  Government 
Furnished 


1  Unit/Unit  Providing  LUFS  Support 
1  (Program  Element  Code) 

Unit/OPFAC  this  PR  Supports 
(Cost  Center) 


|  ESU  Alameda/MLCP(T) 


Submit  Initial  Data  -  Start  a  New  Purchase  Request  Form 


Figure  8.43  On-line  Purchase  Request  -  Part  1 
c.  On-line  Purchase  Request  -  Part  1:  This  is  the  first  half  of  a  Purchase 
Request  Form.  It  contains  all  the  same  fields,  organized  the  same  way,  as  a  traditional 
paper  PR  form. 


Ill 


Figure  8.44  On-line  Purchase  Request  -  Part  2 
d.  On-line  Purchase  Request  -  Part  2:  This  is  the  second  half  of  a  Purchase 
Request  Form.  It  contains  all  fields  for  ordering  up  to  five  items.  If  the  user  wants  to 
order  more  than  five,  they  can  press  the  "Order  More"  button  and  fill  out  another  five 
items. 
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ROCUREMENT 

ROCESS 


Electronic  Support  Unit  Alameda  Intranet 


Request 

APIDLY 


The  following  Purchase  Request  has  been  submitted  and  is  now  pending  For  Action: 


Purchase  Request  Number 

1 .  Person  to  contact 

2.  Type  of  Request: 

3.  Orig  Office  Branch  &  Location 

4.  Suggested  Source  of  Supply 


5  Approving  Officials 
Authorized  Requistioner 
Accounting  Certification  Officer : 
Supervisor:  \  / 

•'  Requester:":. '  T-?  •; 

6.  Consignee  and  Destination: 


7.  Date  Required 
8  Government  ttrriished: 
TJnit/Unit  Providingpj^  ^ 
UnitfOPFAGthis  PR  Si^pprtsY 


LT  Todd  Hannah  ()  1 234567;  Location: 

New  Request 

Electronic  Systems  Branch; 

Joes  Hardware 
Downtown 

Monterey,  CA93940:  5555555  ext. 

Attn: 

CDR  Ed  Lane,  XO 
SKC  Darvin  Bennett,  Storekeeper 
•  LT  Barney  Fife,  Electronic  Systems  Branch 
LT  Todd  Hannah, 

COMMANDING  OFFICER,  ESU  ALAMEDA 
BLDG  21  RM1 28  COAST  GUARD  ISLAND 
ALAMEDA  CA 

No 

30/0/5A 

53700 


litem  9.  Description  of  Items  or  Services 

In  umber 

Qty 

Unit 

Unit  Cost 

1  Hammers 

15 

EA 

6 

edit 

2  Nails 

15 

DZ 

5 

edit 

Edit  Admin  Data  (1-8) 


■  '  ••  -i  .  .  -  --  •  *•  -4-  '  . --.v , ».•  • 

Add  New  Item  (9)  I  Go  to  Supply  Home 


Mark  Order  as  Received 


Fill  osA Another  Supply D^aseStat^  '  PastpRArchive  view Status Loeffistorv  HHH 
3aest  .  Page  .  - 7—— -  — — - — ^ 


K  '  Purchase  Request 


Figure  8.45  Complete  Purchase  Request 


e.  Complete  Purchase  Request:  This  is  the  page  the  viewer  sees  when  the  final 


PR  order  has  been  completed  and  has  been  submitted  to  the  database. 
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Only  the  Storekeeper  should  be  Assigning  PR  Numbers. 

DO  NOT  ASSIGN  A  PR  NUMBER  IF 
YOU  ARE  NOT  AUTHORIZED  TO  DO  SO. 

If  necesseuy.  go  back  using  the  back  button 


-  ; .  r 


'  1  OK 


Figure  8.46  Warning  About  Assigning  PR  Numbers 


Electronic  Support  Unit  Alameda  Intranet 


The  following  PR  will  be  assigned  a  PR  Number 


:S**r5, 

■■asxm: 


Assigne  PR  Number  here:  | . 

Click  to  Assign  PR  #  I;  Cancel 


1.  Pronto  contact:  LT  Todd  Hannah  ()  1234567;  Location: 

2  Type  of  Request:  New  Request 

3.  Orig  Office  Branch  &  Location  ; 

4.  Suggested  Source  of  Simply  Joes  Hardware 

•\  •  ?  Downtown 

Monterey,  CA  93940:  5555555  ext. 

•  Attn: 

5.  Approving  Officials 

Figure  8.47  Storekeeper  Form  to  Assign  PR  Number 
f.  Storekeeper  Form  to  Assign  PR  Number:  The  Storekeeper  can  use  this  form 
to  assign  a  PR  number  to  a  submitted  request  once  the  funding  and  other  administrative 
tasks  have  been  completed.  The  warning  box  alerts  users  that  only  the  Storekeeper  is 
authorized  to  assign  PR  numbers. 


Electronic  Support  Unit  Alameda  Intranet 


Status  Log  Updates 
Status  Log  Update:  Updates  this  PR 


Update  Text:  T:  K. 

JoeTs  Hardware  is  still  out  of  hammers. 

ipr] 

Updated  By:  •  ;/  7 

Hannah,  Todd  (LT)  f§| 

.  Dke  of Update:  '  .  ' ' 

5/4/98 . k .  ; 

Submit  Update  |  Reset  | 

°r 

Marie  Order  as  Received 

Status  Log  Update  History:  History  of  Status  Log  updates  for  this  PR 


[pate  of  Update  Updated  by:  Update  Text: 


PR# 

Date  Submitted  .f.:  5/4/98 

Point  of  Contact  LT  Todd  Hannah  (  )  1 2345  67 ;  Location: 


~  VilwSt^  :Su jppivSaB)ase  Stlus  Page 


"  PastPRArStf^'^' 


Figure  8.48  Status  Log  Update  Form 


g.  Status  Log  Update:  The  user  may  use  this  form  to  update  the  database  status 


log.  On  the  Intranet,  this  becomes  an  individual  responsibility.  Before  the  Intranet 
solution,  the  Storekeeper  had  to  maintain  the  status  updates  of  all  PRs  because  all  the  PR 


forms  were  kept  in  a  paper  file  folder.  By  distributing  the  PR  status  information  across 
the  Intranet,  the  unreasonable  burden  of  tracking  everyone's  PRs  is  distributed  from  the 
Storekeeper  to  the  entire  organization.  This  was  one  of  the  Commands  top  goals. 
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The  following  PR  will  be  MARKED  AS  RECEIVED 


Enter  the  Date  the  order  was  received  (mm/dd/yy  format) :  (5/5/08 

Cancel  I 


Click  to  Enter  Date  Received 


Procurement  Request  Number:  123123 

1.  Person  to  contact:  LTTodd  Hannah  ()  1234567;  Location: 

2.  Type  of  Request:  New  Request 

3.  Orig  Office  Branch  &  Location  ; 

4.  Suggested  Source  of  Simply  Joes  Hardware 

Downtown 

:  Monterey,  CA 93940:  5555555  ext. 

Attn: 


Figure  8.49  Order  Marked  as  Received 


h.  Order  Marked  as  Received:  This  form  is  used  so  those  individuals  may  mark 
off  when  a  PR  order  process  has  been  completed.  This  removes  the  PR  from  the 
outstanding  PR  "To  Do"  lists  on  the  Supply  Database  Home  Page.  The  information  is 
recorded  in  the  Past  PR  Archive  page  (not  shown). 
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J.  SECURITY  APPLICATION 


1.  Introduction 

The  Security  Application  is  present  throughout  all  other  applications  on  the 
Intranet.  Security  is  handled  on  a  page  by  page  basis  as  explained  in  detail  in  Chapter 
VII.  This  section  provides  screen  shots  of  successful  and  unsuccessful  logins. 


2.  Web  Pages  of  the  Security  Application 

a.  List  of  Web  Page  Figures:  The  following  table  lists  the  names  of  the  Web 
pages  of  this  application  and  the  corresponding  figure  numbers. 


Web  Page 

Figure 

Home  Page  with  Security  Application  Login  Highlighted 

8.51 

Successful  Login 

8.52 

Unsuccessful  Login 

8.53 

Access  Denied 

8.54 

Figure  8.50  Table  of  Web  Pages  and  Corresponding  Figures 
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Electronic  Support  Unit  Alameda  Intranet 


Welcome  to  the  ESU  Alameda  Intranet  Site!  As  a  guest  user  you  may  browse  any 
pages  found  under  the  "Extranet"  banner  in  the  navigation  bar.  All  information  is  For 
Official  Use  Only.  :;r  :  - : .  m:. 


in 


-au  pages.;  - 


General  Announcements 


Aimouncement 


Posted  by 


Post  a  New  Announcement 


Security 


|  Intranet  Login  } 

Allows  for  access  to  pages  intended  | 
for  ESU  naeiribeis  only.  Yon  MUST  ! 
login  to  have  access  to  databases,  j 

Username:! 

user  j 

Password:  j 

i 

-  |Lp|tiri5: 

".j 

Personnel  on  Leave  Today 


Leave  Period  ends  on: 


Doolittle,  Doctor  (LI)  5/1 5/98  after  15  days. 

Leave  Summarv  •  ' 


Personnel  TAD  Today 


TADSumn 


'..1: 


'  --r 


Figure  8.51  Home  Page  with  Security  Application  Highlighted 
b.  Home  Page  with  Security  Application  highlighted:  This  is  the  page  the  user 
logs  into  the  Intranet  from. 
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pp® 

Electronic  Support  Unit  Alameda  Intranet 

1 

Your  Login  Succeeded! 

_ 1 

You  are  logged  in  as:  admin 

Security  Session  Access  Level  admin 

Please  return  to  the  ESU  Home  page  to  begin. 


Figure  8.52  Successful  Login 


Your  Login  Failed 


Please  return  to  the  ESU  Home  page  to  login  again  or  access  areas  that  require  no  security  privileges. 

Figure  8.53  Unsuccessful  Login 


Electronic  Support  Unit  Alameda  Intranet 


You  are  logged  in  as 
Security  Session  Access  Level 


You  do  not  have  access  to  that  web  page.  Ihe  page  you  have  requested  requires  for  you  to  log  in  at  a 


LOG-IN: 


Figure  8.54  Access  Denied 

c.  Security  Login  Pages:  The  top  two  pages  are  displayed  for  either  a  successful 
or  an  unsuccessful  login  attempt.  The  Access  Denied  page  is  displayed  when  a  user 
requests  a  page  that  is  restricted  to  a  security  access  level  which  is  higher  than  what  the 
user  is  logged  in  at. 
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K.  CONCLUSION 


It  is  difficult  to  capture  the  way  a  software  system  works  by  presenting  it  on 
paper.  There  are  over  80  Web  pages  on  the  Intranet  and,  of  course,  not  all  of  them  were 
presented  in  this  chapter.  This  section  attempted  to  describe  the  basic  feel  and 
functionality  of  the  Intranet  with  selected  screen  shots  from  its  applications. 
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IX.  IMPLEMENTATION 


A.  INTRODUCTION 

The  Intranet  will  be  installed  at  the  ESU  about  six  months  after  the  project’s 
initiation.  From  a  technical  standpoint,  the  physical  installation  is  straightforward.  The 
implementation  process,  however,  is  far  more  than  just  the  physical  installation  of 
software.  It  involves  complex  management  issues  of  organizational  change  leveraged 
through  information  technology.  The  final  outcome  of  the  implementation  process,  and 
its  impact  on  the  organization,  will  not  be  fully  understood  for  quite  some  time. 

The  goal  of  this  project  is  a  successful  implementation  of  a  new  Intranet  that  adds 
value  to  the  ESU.  The  minimum  definition  of  success  is  an  implementation  resulting  in  a 
prototype.  This  basic  prototype  could  then  serve  as  a  foundation  for  future  independent 
development  efforts.  If  the  implementation  is  more  successful,  the  Intranet  could  become 
an  operational,  working  product  that  would  be  used  daily  and  maintained,  and  improved 
locally. 

The  Intranet  is  a  powerful,  technically  sound,  well-designed  and  fully  functional 
tool  that  has  the  potential  to  add  significant  value  to  the  ESU  Command.  The  fact  that 
the  Intranet  is  a  high  quality  product,  however,  does  not  guarantee  its  acceptance  or  use 
throughout  the  organization. 

Implementation  is  an  organizational  wide  process  of  change  that  will  alter  current 
lines  of  communication  and  business  practices.  This  change  has  both  social  and  technical 
aspects  (Lawrence,  197).  The  development  of  the  product,  up  to  this  point,  has  focused 
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on  the  technical  aspects  of  analysis  and  physical  design.  It  is,  however,  the  social  aspect 
of  the  change  that  determines  the  final  result. 

The  implementation  process  includes  both  the  Implementation  and  Maintenance 
Phases  of  the  Waterfall  Model.  This  section  focuses  on  the  management  and  change 
issues  that  are  involved,  and  a  formula  for  change  is  introduced.  The  change  formula  is  a 
tool  for  assessing  organizational  readiness  and  a  plan  of  action  for  change. 

B.  IMPLEMENTATION 

The  Implementation  and  Maintenance  Phases  of  the  Waterfall  Model  include 
steps  such  as  installing  the  new  software,  preparing  the  training  plan,  and  establishing  the 
long-term  maintenance  schedule  for  the  new  system.  These  are  the  technical  steps  that 
must  be  taken  for  any  successful  system’s  implementation. 

The  technical  steps  are  essential  to  a  successful  implementation,  but  the  social 
considerations  are  what  determine  the  final  outcome.  Introducing  an  information  system, 
which  radically  alters  the  way  people  communicate,  will  have  social  consequences  for  the 
entire  organization.  These  consequences,  and  different  ways  of  seeing  and  managing 
them,  should  be  considered. 

There  is  a  wide  spectrum  of  possible  organizational  responses  to  the  new  tool.  At 
one  end  of  the  spectrum,  the  Intranet  could  be  resisted,  completely  ignored,  and  never 
used  after  the  first  install  day.  At  the  other  end,  it  could  be  adopted  wholeheartedly  and 
the  ESU  could  take  complete  ownership  for  the  system.  ESU  ownership  means  they 
would  use  it  daily,  maintain  it  locally,  and  improve  it  constantly.  There  are  many  reasons 
why  the  implementation  outcome  might  be  somewhere  in  the  middle.  Even  if  the  Intranet 
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is  simply  recognized  as  a  “vision  of  future  possibilities”*  the  goal  of  this  thesis  will  have 
been  met. 


Increasing  Command  Investment  and  Ownership 

- ► 


Figure  9. 1  illustrates  the  possible  spectrum  of  Intranet  implementation  outcomes 
and  the  corresponding  organizational  reactions  to  them.  In  the  figure,  “functional”  means 
some  employees  use  the  system.  “Operational”  means  the  system  is  relied  upon  as  a  tool 
for  the  ESU’s  daily  business.  “Owned”  indicates  a  Command  investment  of  resources  for 
both  maintenance  and  improvement  of  the  new  systems.  The  spectrum  of  success 
increases  from  left  to  right  with  a  corresponding  increase  of  Command  investment  and 
ownership. 

In  all  possible  outcomes,  the  Intranet  can  serve  as  one  prototype  in  the  Rapid 
Prototyping  model  of  systems  development.  Rapid  Prototyping,  as  explained  in  Chapter 
IV,  is  an  iterative  process  of  development.  The  left  end  of  the  spectrum  in  Figure  9. 1 
corresponds  to  the  early  prototypes  of  the  Rapid  Prototyping  iterative  development  model 
(see  Figure  4.3).  The  increasing  Command  investment  and  ownership  of  the  system 
found  towards  the  right  end  of  the  spectrum  correspond  to  more  mature  prototypes  which 
the  Command  itself  could  test,  revise  and  enhance  to  their  own  requirements. 
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There  are  many  possible  reasons  why  the  implementation  process  might  not  be 
successful.  If  old  business  processes  still  occur,  in  parallel  with  the  new  Intranet 
methods,  confusion  could  arise.  If  the  new  technology  is  misused  by  employees  who 
perform  unauthorized  deletions  of  records  or  mistaken  submission  of  on-line  forms,  the 
Command  could  conclude  that  the  costs  of  doing  business  a  new  way  outweigh  benefits 
of  the  old.  Resistance  to  change,  a  poor  maintenance  plan,  no  backup  policy,  no  training 
plan,  or  no  commitment  to  improving  the  Intranet  are  all  possible  reasons  that  could  also 
lead  to  a  failed  implementation. 

The  solution  to  these  potential  problems  is  to  consider  the  Intranet 
implementation  from  a  systems  thinking  perspective.  The  new  Intranet  must  be 
considered  as  a  dynamic,  living  entity  that  must  have  attention.  The  databases  require 
current,  accurate  data  in  order  to  be  relevant.  The  phone  book  application  database,  for 
example,  must  be  populated  with  accurate  phone  numbers.  The  Intranet  can  not  be 
installed  and  be  expected  to  maintain  itself.  A  complete  management  plan,  including 
decisions  on  who  will  own  the  Intranet,  who  will  maintain  it,  who  will  enter  data,  and 
who  will  use  it,  must  be  considered.  The  new  Intranet  policy  should,  at  a  minimum, 
address  security  issues,  acceptable  use  instructions,  and  a  backup  plan. 

C.  STRATEGIES  FOR  CHANGE 

1.  Introduction 

A  general  strategy  for  introducing  change  into  an  organization  includes  three 
basic  stages.  First,  the  organization  must  be  “unfrozen”.  This  is  when  the  organization 
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prepares  for  a  change.  The  leadership  should  foster  an  environment  that  is  dissatisfied 
with  the  status  quo.  The  middle  stage  is  the  transition  period  when  the  change  actually 
occurs.  An  ideal  vision  of  the  future  state,  after  the  change  has  been  implemented,  should 
be  articulated  by  the  change  advocates.  The  final  stage  is  when  the  change  has  been 
completed.  During  this  stage,  the  organization  should  support  and  maintain  the  change. 

The  General  Accounting  Office  (GAO)  Executive  Guide  on  Improving  Mission 
Performance  Through  Strategic  Information  Management  and  Technology  describes  three 
key  processes  that  the  GAO  considers  critical  to  introducing  an  Information  Technology 
change  to  an  organization.  They  are:  “(1)  deciding  to  work  differently...  (2)  directing 
resources  ...  and  (3)  supporting”  (GAO  Report,  7).  These  three  processes  parallel  the 
three  stages  of  unfreezing,  transitioning,  and  supporting  change. 

The  following  section  introduces  a  change  formula  that  is  useful  for  assessing  the 
first  two  stages  of  introducing  change,  unfreezing  and  transitioning.  The  next  section 
introduces  the  concept  of  a  systems  loop.  The  systems  loop  describes  the  possible 
outcome  of  a  change  after  it  has  been  implemented  and  is  in  the  third  and  final  stage  of 
maintenance  and  support. 

2.  Change  Formula 

a.  Definition:  One  way  of  introducing  change  is  to  consider  it  in  the  context  of  a 
formula  for  change.  The  change  formula,  adapted  from  Professor  Michael  Beer’s  article 
"Leading  Change"  (p.3,  Beer,  1988),  can  be  used  to  assess  organizational  readiness  for 
change  and  to  implement  the  change.  The  change  formula,  and  its  relevance  to  the  ESU 
Intranet  implementation,  is  presented  below. 
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successful  “dissatisfaction  with  present”  X  >“cost  of 

change  =  “ideal  vision  of  future”  X  change” 

“process  of  change” 

The  formula  states  that  there  are  three  critical  factors  that  must  be  considered  for  a 
successful  change.  These  factors  are  multiplied,  meaning  if  one  is  missing  then  the  whole 
formula  is  equal  to  zero,  and  the  change  will  fail.  All  three  factors  must  be  present  with 
sufficient  strength  to  be  greater  than  the  cost  of  change  (p.3,  Beer,  1988). 

b.  Successful  Change:  Implementation  of  the  Intranet  would  be  a  successful 
change  for  the  ESU.  The  Intranet  would  add  value  to  the  ESU  by  allowing  them  to  do 
current  business  processes  in  a  new,  more  efficient  and  effective,  way.  The  change  could 
be  considered  increasingly  successful  as  one  moves  farther  to  the  left  on  the  scale 
presented  in  Figure  9.1. 

c.  Dissatisfaction  with  Present:  Dissatisfaction  with  the  status  quo  is  critical 
because  it  provides  the  energy  for  overcoming  organizational  resistance  to  change  (p.4, 
Beer,  1988).  An  advocate  of  change  must  be  someone  who  is  unsatisfied  with  the  current 
way  of  doing  business  and  believes  that  there  is  a  better  way.  During  the  requirements 
capture  phase  of  the  project,  the  Command  at  ESU  indicated  that  there  were  in  fact  some 
processes  that  they  would  like  to  see  improved.  Each  of  these  goals  are  technically 
addressed  with  functioning  Intranet  applications.  The  Intranet  was  developed  to 
specifically  address  these  problems  and  issues. 

From  a  top  down  perspective,  the  Command  must  become  the  advocate  of  change. 
The  Command  can  create  an  environment  that  is  ready  for  it  by  insisting  on  using  the 
Intranet  applications.  Urging  employees  to  do  business  in  a  new  way  will  indicate  to  the 
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rest  of  the  organization  that  the  Command  is  not  satisfied  with  the  status  quo.  This  will 
create  an  environment  that  is  ready  for  change.  Command  advocacy  of  the  Intranet  will 
send  the  signal  that  is  good  to  use  the  Intranet. 

If  the  Command  is  content  with  old  business  processes,  in  spite  of  the  availability 
of  new  Intranet  solutions,  then  they  are  effectively  satisfied  with  the  status  quo.  If  the 
Command  doesn’t  create  the  environment  for  change  through  advocacy,  then  the  rest  of 
the  organization  will  not  have  the  incentives  to  change. 

An  environment  of  dissatisfaction  with  the  status  quo  can  also  be  fostered  from 
the  bottom  up.  If  the  employees  of  the  organization  find  that  the  Intranet  is  a  technically 
sound  solution  that  has  potential  to  add  value  to  their  work,  then  they  are  likely  to  use  it. 
The  more  key  personnel  who  share  this  idea  that  the  Intranet  is  useful,  or  has  the  potential 
to  be  of  use,  the  more  likely  the  environment  for  change  will  be  ready. 

d.  Ideal  Vision  of  the  Future:  Many  personnel  at  ESU  must  share  the  “vision  of 
what  is  possible”  with  a  new  Intranet.  They  must  recognize  it  as  an  improvement  over 
the  status  quo.  A  sufficient  number  of  key  stakeholders  must  understand  how  new 
Intranet  applications  will  add  value  to  their  daily  work.  The  ESU  Command  can  do  this 
by  ensuring  all  personnel  have  seen  the  system  and  are  trained  in  how  to  use  it. 

e.  Progress  of  the  Change:  The  change  to  using  the  Intranet  will  not  occur 
overnight.  Simply  dropping  the  Intranet  into  the  ESU  will  not  mean  it  will  be  adopted 
immediately.  The  idea  must  be  sold  to  the  employees  of  the  organization  who  will  judge 
the  new  tool  over  time. 

The  training  and  demonstration  sessions  can  be  used  to  showcase  the  merits  of  the 
system  and  to  gather  feedback  on  ways  it  can  be  improved.  The  Command  could  appoint 
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various  personnel,  who  are  proficient  in  HTML  code,  to  improve  aspects  of  the  system. 
People  will  become  committed  to  a  project  that  they  help  create  (p.5,  Beer,  1988). 

Initially,  the  physical  installation  of  the  Intranet  is  critical  to  get  right.  The  first 
few  days  of  its  deployment  is  a  crucial  time  when  most  people  will  form  strong  opinions 
about  whether  or  not  it  adds  value  to  the  ESU.  Before  it  is  presented  for  ESU  use,  the 
Intranet  should  be  running  normally,  error-free,  on  the  Web  server.  If  the  system  is  slow 
and  inefficient,  plagued  with  frequent  crashes  or  bugs,  is  difficult  to  use  or  has  other 
problems  that  makes  its  use  unpleasant,  then  it  is  unlikely  people  will  make  any  effort  to 
fix  it. 

f.  Cost  of  Change:  Every  change  has  consequences.  Although  the  physical  cost 
of  building  the  Intranet  was  almost  nothing,  the  long-term  cost  of  implementation  is  more 
significant.  The  ESU  will  have  to  invest  resources  into  the  maintenance  of  the  system. 
Someone  will  have  to  spend  time  writing  policy  on  Intranet  use,  validating  the  accuracy 
of  the  databases,  and  ensuring  the  Web  server  is  running.  Training  costs  will  be  incurred 
in  order  to  ensure  someone  at  the  Command  has  a  proficiency  in  administering  the  Web 
server,  authoring  Web  page  code,  and  possibly  even  learning  how  to  use  Active  Server 
Pages. 

The  social  cost  of  implementing  an  Intranet  should  also  be  considered.  The 
Intranet  opens  a  new  avenue  of  communication  across  the  organization.  This  new  means 
of  communication  could,  for  example,  have  consequences  for  job  roles  and  positions  of 
power. 
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g:  Conclusion:  All  of  the  criteria  of  the  change  formula  must  be  present  for  an 
environment  for  change  to  exist.  These  factors  must  cumulatively  outweigh  the  cost  of 
the  change  in  order  for  it  to  have  a  reasonable  chance  of  actually  occurring. 

3.  Systems  Loops 

The  third  and  final  stage  of  introducing  a  change  is  the  support  and  maintenance 
phase  after  the  change  has  occurred.  It  is  anticipated  that  the  introduction  of  the  Intranet 
will  be  met  with  initial  enthusiasm  and  excitement  at  the  ESU.  Since  it  is  a  technically 
sound  product,  the  Command  is  likely  to  realize  the  potential  the  new  system  has  to  add 
value  to  the  organization.  The  excitement  is  likely  to  generate  Command  and 
organizational  investment  in  the  product,  which  will  in  turn  lead  to  growth  and  use  of  the 
Intranet.  Initially,  the  implementation  is  likely  to  be  a  success. 

At  some  point,  however,  the  growth  experienced  at  the  beginning  will  slow.  If  the 
Command  has  not  heeded  the  advice  about  preparing  the  environment  for  change 
presented  above,  then  the  limits  to  growth  will  quickly  appear.  The  slowdown  could 
become  so  significant  that  eventually  everyone  stops  using  the  system,  marking  the  end 
of  the  value  it  can  add  to  the  ESU’s  daily  operations. 

This  process  of  growth  and  then  slowing  will  almost  certainly  happen  at  some 
point  during  the  implementation  process.  The  only  question  is  if  it  will  happen  sooner 
rather  than  later.  The  key  principle  for  the  Command  to  consider  is  that  removing  the 
factors  that  limit  growth  will  delay  the  eventual  slowing. 
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Systems  Diagram  of 


Figure  9.2  Limits  to  Growth  System  Loop  of  Intranet  Implementation 

This  diagram  of  considering  systems  as  loops  of  growth  and  slowing  is  adapted 
from  Peter  Senge’s  "Limits  to  Growth"  system  loop  archetype  (p.73,  Senge,  1990).  It  is 
presented  in  the  context  of  an  ESU  Intranet  implementation.  The  limiting  factor  is 
represented  as  a  poor  maintenance  plan,  which  could  lead  to  system  errors,  corrupt  data, 
or  security  violations.  The  consequences  of  the  limiting  factor  reveal  themselves  after  a 
period  of  delay. 

D.  PHYSICAL  INSTALLATION 

The  technical  aspects  of  a  physical  installation  are  straightforward.  The  general 
steps  were  outlined  in  Chapter  VII.  On-line  documentation  regarding  setup  and 
installation  of  these  commercially  available  products  is  extensive. 

The  Intranet  software  requirements  must  exactly  match  between  the  NPS  machine 
the  Intranet  was  developed  on  and  the  ESU  Web  server  the  Intranet  will  actually  be 
deployed  on.  The  ESU  had  to  prepare  their  Web  server  with  the  latest  software  versions 
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used  for  the  project  development.  Some  upgrades  were  necessary  to  host  the  site.  The 
physical  installation  will  occur  over  the  summer  of  1998. 

E.  CONCLUSION 

There  is  little  doubt  that  the  Intranet  is  a  quality  product  that  can  add  significant 
value  to  the  organization.  Technically,  it  operates  reliably,  without  errors,  and  has  a 
clean,  easy  to  use  design.  Unfortunately,  successful  integration  of  the  Intranet  into  the 
ESU  will  not  depend  on  its  technical  merits.  It  is  the  social  aspect  of  the  change  that  will 
determine  the  final  outcome  of  the  implementation  process.  It  may  take  up  to  a  year  to 
accurately  judge  the  final  effects  of  introducing  Intranet  technologies  into  the  ESU 
Alameda  workplace. 
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X.  CONCLUSION 


The  development  effort  resulted  in  a  functional,  operational  Intranet  for  a  USCG 
unit.  Commercial  development  of  such  a  system  would  cost  well  into  the  thousands  of 
dollars. 

This  prototype  for  this  Intranet  is  generic  enough  to  be  adaptable  to  almost  any 
USCG  setting.  It  provides  solutions  to  business  processes  that  are  common  at  almost  all 
USCG  units.  Applications  for  up  to  date  phone  listings,  recall  logs,  leave  requests, 
temporary  duty  requests,  marks  schedules,  and  unit-wide  announcements  would  probably 
be  desirable  to  have  at  any  USCG  unit. 

Whether  the  implementation  process  for  this  Intranet  leads  to  an  operational  tool 
that  is  used  daily,  or  if  the  implementation  leads  to  a  simple  prototype,  this  thesis  has 
been  a  success.  A  simple  idea  has  grown  into  a  reality.  By  following  an  information 
systems  software  design  methodology,  a  working  product  has  been  developed.  Along  the 
way  the  author  has  acquired  technical  skills  in  software  development,  business  analysis 
skills  for  information  systems  requirements  analysis,  and  managerial  skills  for 
implementing  an  information  systems  change  into  an  organization. 


133 


APPENDIX  A.  ASP  APPLICATION  -  DESIGN  AND  CODE 


A.  INTRODUCTION 

The  Announcements  Application  on-line  form  is  used  as  example  here  to  illustrate 
the  development  of  an  Active  Server  Pages  Web  page.  An  ASP  page,  ending  in  the 
".asp"  extension,  consists  of  both  HTML  code  and  Visual  Basic  Script.  The  HTML  code 
is  mostly  accomplished  with  a  visual  Web  page  development  tool,  Front  Page  98  Editor 
in  this  case.  The  VB  Script  had  to  be  written  into  the  page  line  by  line,  without  the 
assistance  of  any  visual  development  environment.  The  VB  Script  code  is  shown  in 
Figures  A.2  through  A.4  as  comments  on  the  FP98  Editor  page.  (The  real  code  is  inside 
the  dark  boxes.) 

There  are  over  80  Web  pages  on  the  ESU  Intranet.  Most  of  them  are  Active 
Server  Pages.  The  code  for  each  page  takes  up  roughly  five  to  ten  typewritten  pages  of 
HTML  and  VB  Script.  Listing  hundreds  of  pages  of  code  here  is  impractical,  so  what 
follows  is  a  look  at  the  code,  for  just  one  page,  through  the  visual  development 
environment  of  Front  Page  98. 

This  ASP  page  is  named  "announcements_form.asp".  It  is  an  on-line  form  that 
requests  user  input  and  then  updates  the  Announcements  database  with  it.  The  form  is 
spread  across  three  figures  because  it  would  not  fit  on  just  one  page.  The  basic  concepts 
of  using  ASP  to  perform  these  operations  are  briefly  explained.  These  operations  are 
similar  throughout  all  the  pages  of  the  Intranet.  The  5  pages  of  HTML  and  ASP  code  that 
are  behind  this  visual  development  are  also  included. 
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B.  FRONT  PAGE  98  VISUAL  DEVELOPMENT  ENVIRONMENT  OF 
ANNOUNCEMENTS  FORM.ASP 


Navigation 

Hyperlinks 


All  Folders:  ; .  - -.  .K;  ;  ; 
B'S  http://1 27.6.0.1  /prototyped 
UQ  ^borders 
;--El  ^private 
j~423  images 

i)~Q  Personnel_Database 
I  | -  ^  announcements 
1423  filetools 
I  {-423  leave 
|  U03  marks 

;-  42]  reports 
LC3  TAD 
L-*a  work 

j-C3  pows 

j~Bl  subnets 
[■■-23  Supply_Database 
b23  test_code 
MSS  webnav 


Gontents  of  ^announcements* ; 
^ Name  •;•••''•  / 

Qjadovbs.inc  j 
Hi  announcement_details.asp 
i  announcements  Jorm.asp 
Hi  de!ete_announcementasp 
Hi  do_the_delete.asp 
Hi  past_Announcement_archiv... 


Trtfe  -  ,  j 

Personnel_Database/announcerr 
Announcement  Headline  Details  j 
General  Announcements  Form 
Delete  Announcement 
Do  the  Delete 

Past  Announcement  Archive 


n  INUM.  ^ 


Figure  A.1  View  of  Intranet  in  Front  Page  98  Explorer 
The  entire  EStJ  Alameda  Intranet  is  shown  here  in  the  FP98  Explorer  window. 


The  Announcements  Application  folder  is  open. 
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>  FrontPage  Editor 


;•  file  Edit  ytew  fio  insert  Fflfmat  Xools  T^}!e  Fiam©:  i65ndow  Melp 


f  X  \<$\&m'2i\s&\  <-  +  IgjOlRT]^ 


flCNone). 


^[[(deleuttfonQ  JV j  [  X  a  |  B  V  If  [ #  ^ *  M  ] J~  gjifcfe  | 


iPJ^IO  j  '§>'■#'•  ».<*  <$>  L/<2|Sc  § 


j  General  Announcements  Form 


Electronic  Support  Unit  Alameda  Intranet^ 


Comment:  include  adovbs.indlTI 

■Comment:  IF  Request("Content_Lenglii")=0  THEN*  SHOW  THE  FORMH 

Add  a  new  Announcement  to  the  Home  Pagef 

These  announcements  are  for  general  all-hands  broadcast  and  will  be  visible  to  ANYONE  visiting  the  ESU  Alameda  Home 
Page.  Bear  this  in  mind  when  making  a  post  and  keep  it  professional.  Any  validated  ESU  Alameda  Intranet  user  may  post 
announcements.^ 


Point  of  Contactf  |J 


[pate  ofpostfl 


:||  <%  Do  While  Not  RS.EOF  %>  fg 

ji  Comment:  7/  Set  up  connection  and  run  query  -> 
j  Set  ObjDBConnecti  on  =  Server.  CreateObj  ect("ADODB.  Connection”)  +* 

\  bbjDBConnectionOpen  " phonebook"  7/  Pre-deimed  ODBC  data  source 

;SQL  =  "SELECT  rate,  FirstName,  LasfName,  SSN  FROM  PERSON  ORDER  BY  LastName"  -J 

I  jSet  RS  =  ObjDBCorinection.Execute(SQL)  ^ 

|j*J  ' 

SELECT  BOX  *1  . 

j  j<select  SEE="i”  NAME="POC">  ^ 
i  <option>  <%  Do  While  Not  RS.EOF  %>  </ option>  ^ 

•koption  value="<%=  RS("LastName")  &  ”,  "  &  RS("FirstName")  &  "  (”  &  RS("rate")  &  ")"  %>  ">  <%= 
|JtS("LasfName”)  &  ",  "«&  RS("FirsfName”)  &”(”  &  RS(”rate”)  &  ")"  %>  <%  RS.MoveNext%><%Loop 
!%></option> -J 

|<option>  <%ObjDBConnection.Close%>  </option>  ^ 

| Comment:  i^«»e.write- "k^ng^igp'  ^ 

I  response,  write  date 
|  response. write  M</strongx^big>”^ 

Ji*L 


iDate  post  expires  :{|<^DateAdd  (~,,d,,,i<.Dat|  | 

[and  removed  from 
jlHomePage^f  jl/ | 


Figure  A.2  Announcements  Form  in  FP98  Editor  (Part  1) 

The  first  part  of  the  form  is  shown  here.  Using  an  IF-THEN  LOOP,  the  page 
checks  to  see  if  the  form  has  been  filled  out  yet.  If  it  has  not,  then  it  displays  the 


announcement  form. 


137 


[Announcement 

Headline  for 
[Homepage: 

jiOPlease  limit  to  one 
?or  two  lines  without 
[icarriage  returns.)!! 

rr 

SET - - - - - - - wF 

. r 

H  !H: 

Ik 

. . . : . : . i;> 

HH 

t 

sh - — — — ■ — — - wr 

. IS 

11 

i  is 

as 

L 

. . . m 

Post  Announcement  to  ESU  Alameda  Home  Page  .  \  K  \0 

■Comment:  ELSE  ’  Do  the  update^] 

■Comment:  'll  Set  up  connection  and  run  query  *-■ 

Set  Corm  =  Server.  CreateObject(”ADODB.  Connection")  +* 

Conn.  Open  "announcements"  '//  Pre-defined  ODBC  data  source 

SQL  =  "SELECT  *  PROM  Announcements"  ^ 

set  rs  -  server. CreateObject("ADODB.Recordset")  ^ 

//  unlock  recordset  RS  ^ 

•X'iv 

;|L 

i-X' 

RS.LockType  =  adLockOptimistic  «-* 

«J 

1 U  create  and  open  a  new  RS 

RS.open  SQL,  Conn,  adOperiKeySet '  openkeyset  to  navigate  and  reuse  this  recordset  «-> 
’  //update  the  recordset  — 1 

'//  note  die  use  of  AddNew  as  ALL  requests  will  be  new 

poc  =  requestform("poc") 
begin_date  =  date() 

end_date  =  request.form("end_date")  ^ 
announcement  =  requestfonn(Mannouncement”) 
details  —  requestformf'details")  -1 


Figure  A.3  Announcements  Form  in  FP98  Editor  (Part  2) 

This  is  the  second  part  of  the  form.  When  the  user  completes  the  form  and 


presses  the  submit  button,  the  form  is  submitted  back  to  itself  on  this  same  page.  The  IF- 
THEN  LOOP  will  detect  that  data  has  been  submitted  and  the  page  will  begin  processing 
after  the  ELSE 1  DO  THE  UPDATE  statement  shown  above. 

This  form  is  a  typical  ASP  Web  page  that  collects  information  from  the  user, 
inserts  the  data  into  an  ODBC  database,  and  displays  the  results.  The  code  used  on  this 
page  is  re-usable  in  the  sense  that  the  same  general  method  is  used  throughout  the  ESU 
Intranet. 
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RS.AddNew^J 
RSCpoc")  ~  poc  ^ 

RS(”begm_date”)  =  begin_dale 
RS("end_date")  -  endjiate  +* 
RS("amouncemenl")  ~  announcement  ^ 
RS(”details") —  details  ^ 

'  //UPDATE  it  -4 
RS.update 


*  Close  connection  +*■ 
Conn,  closed 


Success.  J 

Your  announcement  has  been  posted  to  the  ESU  Alameda  home  page  as  follows:!! 


Figure  A.4  Announcements  Form  in  FP98  Editor  (Part  3) 


The  ASP  pseudocode  for  the  update  is  presented  below  (see  Figures  A.3  and  A.4): 

•  a  Connection  object  named  "Conn"  is  created  with  the  ODBC  datasource 
"Announcements" 

•  a  variable  named  SQL  is  assigned  as  an  SQL  statement 

•  a  RecordSet  object  named  "rs"  is  created 

•  the  open  method  is  used  on  the  object  "rs"  which  runs  the  SQL 

•  a  new  RecordSet  is  created 

•  the  RecordSet  is  populated  with  the  values  from  the  users  form 

•  the  RecordSet  is  updated 

•  the  connection  is  closed 


C.  HTML  CODE  OF  ANNOUNCEMENTS  FORM.ASP 


The  HTML  code  that  is  behind  the  visual  development  environment  of  Front  Page 
98  is  presented  below'  The  Visual  Basic  Script,  used  for  making  the  Web  page  an  Active 
Server  Page,  is  highlighted  in  bold  typeface. 

<% 

1  ******************************************************************* 

1  *  PERSONNEL  DATABASE  -  Announcements 
*  * 

1  *  For  every  page  that  you  want  to  enable  access  control,  put  the 
include 

’  *  file  and  this  file  in  the  same  directory. 

1  *  Type  <! — #include  file="  .  .  /LoginCheck .  inc"  — > 

1  *  BEFORE  the  <html>  tag  (very  important)  at  the  top  of  the  page  you 
T  *  want  to  contol  access  to.  Also  include  the  following  script. 

i  * 

*  *  If  session ("security”)  =  "Guest"  then 
response . redirect ( " . . /no_access .  asp") 

1  *  end  if 

*  * 

»  ******************************************************************* 

%> 

< ! — #include  f ile=" . . /user_access . inc" — > 

<% 

If  session ("security")  =  "Guest"  then 

response .  redirect  ( "http :  //eg .  nps  .  navy .  mi  1 /pro  to  type /no_ac  cess  .  asp"  ) 
end  if  ~~ 

%> 

<html> 

<head> 

<meta  name=" GENERATOR"  content="Microsoft  FrontPage  3.0"> 

<title>General  Announcements  Form</title> 

<meta  name="Microsoft  Border"  content="t,  default "></head> 

<body  stylesrc="http : //127 .0.0. l/prototype2/_private/style . htm" 
background=" . ./. . /images/Fleck. gif "  vlink="#0000FF">< ! — msnavigation — 
xtable  border="0"  cellpadding="0"  cellspacing="0"  width="100%"xtrxtd> 

ctable  border="0"  width="100%"  cellspacing="0"  cellpadding="0" 
height="45"> 

<tr> 

<td  width="121"  bgcolor="#000040"  height="ll"  valign="top"ximg 
src=". ./. ./images/270. gif"  width="56"  height="42"  alt="270.gif  (13575 
bytes)  "  start="fileopen"x/td> 

<td  width="730"  bgcolor="#000040"  height="ll"  valign="middle"xp 
align=" center" xbigxfont  color="#FFFFFF"  face="Tahoma"xbig>Electronic 
Support  Unit  Alameda  Intranet</bigX/f ontx/bigx/td> 

<td  width="148"  bgcolor="#000040"  height="ll"  valign="top,fXp 
align= "right "ximg  sre-" . . / . . /images/hh60 . jpg"  width="58"  height="42" 
alt="hh60 . jpg  (7125  bytes) "></td> 

</tr> 
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</table> 

</td></tr>< !  — msnavigation — ></table>< !  — msnavigation — xtable 
border="0"  cellpadding="0"  cellspacing="0"  width="100%"xtrx !  — 
msnavigation — xtd  valign="top"> 

<p><! — webbot  bot="PurpleText"  preview="include  adovbs.inc"  — ><! — 
finclude  f ile="adovbs .  inc"  — X/p> 

<pX%IF  Request ("Content_Length")=0  THEN'  SHOW  THE  FORM%X ! — webbot 
bot="PurpleText"  PREVIEW="IF  Request ( &quot;Content_Length&quot; ) =0  THEN' 
SHOW  THE  FORM"  —  x/p> 

<table  border="0"  width="100%"> 

<tr> 

<td  width="100%"  bgcolor= " # FFFF8 0 " ><p 
align=" center "><strongxbig>Add  a  new  Announcement 
to  the  Home  Page</bigx/strongx/td> 

</tr> 

</table> 

<p>These  announcements  are  for  general  all-hands  broadcast  and  will  be 
visible  to  ANYONE 

visiting  the  ESU  Alameda  Home  Page.&nbsp;  Bear  this  in  mind  when  making 
a  post  and  keep  it 

professional . &nbsp;  Any  validated  ESU  Alameda  Intranet  user  may  post 
announcement  s . < /p> 

<form  ACTION="announcements_form.asp"  METHOD="POST"  onsubmit="return 
FrontPage_Forml_Validator  (this)  "  name="FrontPage_Forml''> 

<table  border="0"  width="100%"  cellspacing="4"  cellpadding="0"> 

<tr> 

<td‘  width="35%"  valign="top"  bgcolor="#E8E8E8"xfont 
color="#000000"Xstrong>Point  of 

Contact</strongx/fontx/td> 

<td  width="50%"  valign="top"> 

<% ' //  Set  up  connection  and  run  query 

Set  ObjDBConnection  =  Server. CreateObject ("ADODB. Connection") 

Ob jDBConnection .  Open  "phonebook"  '//  Pre-defined  ODBC  data  source 

SQL  =  "SELECT  rate,  FirstName,  LastName,  SSN  FROM  PERSON  ORDER  BY 
LastName" 

Set  RS  =  Ob  jDBConnection.  Execute  (SQL)  %> 

<pX! — webbot  bo t=  "Validation "  B-Value-Required="TRUE"  B-Disallow-First- 
I tem=" TRUE "  — Xselect  SIZE="1"  NAME="POC"> 

<option>  <%  Do  While  Not  RS.EOF  %>  </option> 

<option  value="<%=  RS ("LastName")  &  ",  "  &  RS ("FirstName")  &  " 

("  &  RS  ( "rate" )  &  ")  "  %>  ">  <%=  RS  ("LastName")  &  ",  "  &  RS  ("FirstName") 

&  "  ("  &  RS  ("rate")  &  ")  "  %>  <%  RS .MoveNext%X%Loop  %X/option> 

<option>  <%Ob jDBConnection. Close%>  </option> 

</select>  </td> 

</tr> 

<tr> 

<td  width="35% "  valign="top"  bgcolor="#E8E8E8"xstrongxfont 
color="#000000">Date  of  post</fontx/strongx/td> 

<td  width="50%"  valign="top"x%response. write  "<strong><big>" 
response . write  date 
response  .write  "</strongx/big>"%> 

</td> 

</tr> 

<tr> 


141 


<td  width="35%"  valign="top"  bgcolor="#E8E8E8"><font 
color="#000000"Xstrong>Date  post 

expires  and  removed  from  Home  Page</strongx/fontx/td> 

<td  width="50% "  valign="top"xinput  TYPE="text" 
VALUE="<%=DateAdd("d", 1,  Date) %>"  SIZE="20"  NAME="end_date">  </td> 

</tr> 

<tr> 

<td  width="35% "  valign="top"  bgcolor="#E8E8E8  "xfont 
color="#000000"Xstrong>Announcement 
Headline  for  Home  Page:  <br> 

</strong><small> { Please  limit  to  one  or  two  lines  without  carriage 
returns .  )  </smallx/fontx/td> 

<td  width="50% "  valign="top"xtextarea  R0WS="2"  COLS="40" 

NAME=  "  announcement ,f  > 

</textareax/td> 

</tr> 

<tr> 

<td  width="35% "  valign="top"  bgcolor="#E8E8E8"xfont 
color="  #000000  "Xstrong>Details  of 
Announcement : <br> 

</strongXsmall> (Only  headline  visible  on  Home  Page.  Details  upon 
following  hyperlink.  No 

carriage  returns  . )  </smallx/fontx/td> 

<td  width=  "50% 11  valign="top"xtextarea  ROWS="4"  COLS="40" 
NAME-,fdetails"> 

</textarea></td> 

</tr> 

</table> 

<div  align="center"xcenter><pxinput  TYPE="submit "  VALUE="Post 
Announcement  to  ESU  Alameda  Home  Page"  NAME="post">  </p> 

</centerX/div> 

</f orm> 

<pX%ELSE  1  Do  the  update%X ! — webbot  bot="PurpleText "  PREVIEW="ELSE  1 
Do  the  update"  — ></p> 

<P> 

<%’//  Set  up  connection  and  run  query 

Set  Conn  =  Server . CreateObject ("ADODB. Connection") 

Conn. Open  "announcements"  f//  Pre-defined  ODBC  data  source 

SQL  =  "SELECT  *  FROM  Announcements" 

set  rs  =  server . CreateObject ("ADODB. Recordset") 

1  //  unlock  recordset  RS 
RS.LockType  =  adLockOptimistic 

1  //  create  and  open  a  new  RS 

RS . open  SQL,  Conn,  adOpenKeySet  T  openkeyset  to  navigate  and  reuse  this 
recordset 

T  //update  the  recordset 

’//  note  the  use  of  AddNew  as  ALL  requests  will  be  new 

poc  =  request. form ("poc") 

begin_jdate  =  date  ( ) 

end_date  =  request,  form  ("end^date") 

announcement  =  request,  form  ("announcement") 

details  =  request . form ("details") 
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RS.AddNew 
RS  ( "poc")  =  poc 
RS  ( "begin_date  " )  =  begin_date 
RS  ("end^date")  =  end_date 
RS  ( "announcement" )  =  announcement 
RS ("details")  =  details 
?  //UPDATE  it 
RS . update 

1  Close  connection 
Conn. close%> 

</p> 

ctable  border="0"  width="100%"> 

<tr> 

<td  width="100%"  bgcolor=" # FFFF8 0 "><p 
align="center "><big><strong><big><big>Success . </big></big></ strongx/big 
xbr> 

Your  announcement  has  been  posted  to  the  ESU  Alameda  home  page  as 
follows : </td> 

</tr> 

</table> 

<table  border="0"  width="558"  cellspacing="4 "  cellpadding="0" 
height="158"> 

<tr> 

<td  width="20%"  valign="top"  height="24 ">Headline :</td> 

<td  width="80%"  bgcolor="#E6FFE6"  valign="top" 
height="24  "X%response.  write  ("<STRONGXBIG>") 
response . write  announcement 
response .  write  ( "</STRONGX/BIG>")  %> 

</td> 

</tr> 

<tr> 

<td  width="20%"  valign="top"  height="21">Details : </td> 

<td  width=?,80%"  bgcolor="#FFFFFF"  valign="topM 
he i ght= "21" X%=details%> 

</td> 

</tr> 

<tr> 

<td  width="20%"  valign="top"  height="22">Posted  on:</td> 

<td  width= "80%"  bgcolor="#E6FFE6"  valign="top" 
height  ="22  "X%=begin__date%> 

</td> 

</tr> 

<tr> 

<td  width="20%"  valign="top"  height="25">Post  expires : </td> 

<td  width="80% "  bgcolor="#FFFFFF"  valign="top"  height="25 "X%= 
end_date%> 

</td> 

</tr> 

<tr> 

<td  width="20%"  valign="top"  height="46">Point  of  Contact:  </td> 

.  <td  width="80%"  bgcolor="#E6FFE6"  valign="top"  height="4 6"X%=poc%> 
</td> 

</tr> 

</table> 

<hr> 
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<div  align="center"Xcenter> 

<table  border="l"  width="35%"> 

<tr> 

<td  width="100%"  bgcolor="#COCOCO"xp  align="center"xa 
href =" . . / . . /home . asp">It ' s  Done . 

Snbsp;  Return  to  Home  Page</ax/td> 

</tr> 

</table> 

</centerx/div> 

<pX%END  IF%X/p> 

<hr> 

<table  border="0"  width="100%"  cellspacing="4 "  cellpadding="0"> 

<tr> 

<td  width="33%"  bgcolor="#C0C0C0"  align="center"xa 
href="announcements_f  orm.  asp"xsmall>Post 
a  New  Announcement</smallx/ax/td> 

<td  width="33%"  bgcolor="#C0C0C0"  align="center"xa 
href="past_Announcement_archive .  asp"xsmall>View 
Past  Announcement  Archive</smallx/ax/td> 

</tr> 

</table> 

Snbsp;  <  !  — msnavigation — x/tdx/trx !  — msnavigation — x/tablex/body> 
</html> 


D.  CONCLUSION 

This  section  was  included  in  order  to  convey  the  aspects  of  programming  a  typical 
interactive  and  dynamic  Web  page  using  HTML,  VBScript  and  ASP. 


144 


APPENDIX  B.  GLOSSARY  OF  TERMS 


AOR  (Area  of  Responsibility) 

This  is  the  term  used  to  describe  the  geographic  area  where  a  USCG  unit  works, 

BACK-END  DATABASE 

This  term  is  used  to  describe  the  database  that  holds  data  used  to  generate  pages  on  an 
Intranet. 

BROWSER 

A  Client  program  (software)  that  is  used  to  look  at  various  kinds  of  Internet  resources. 

DFD  (Data  Flow  Diagram) 

A  graphical  display  that  illustrates  business  processes  and  data  interfaces  from  a  data 
perspective. 

ESU  (Electronic  Systems  Support  Unit) 

A  U.S.  Coast  Guard  facility  that  maintains  and  supports  all  facets  of  Coast  Guard 
electronic  equipment. 

FTP  (File  Transfer  Protocol) 

A  protocol  used  to  transfer  a  complete  file  from  one  computer  to  another. 
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GUI  (Graphical  User  Interface) 

A  GUI  replaces  the  keyboard  commands  typical  of  old-fashioned  computers  with  point- 
and-click  buttons  and  menus. 

HOME  PAGE 

The  Web  page  that  your  browser  is  set  to  use  when  it  starts  up.  The  more  common 
meaning  refers  to  the  main  Web  page  for  a  business,  organization,  person  or  simply  the 
main  page  out  of  a  collection  of  Web  pages 

HTML  (Hypertext  Markup  Language) 

The  coding  language  used  to  create  Hypertext  documents  for  use  on  the  World  Wide 
Web.  HTML  looks  a  lot  like  old-fashioned  typesetting  code,  where  you  surround  a  block 
of  text  with  codes  that  indicate  how  it  should  appear,  additionally,  in  HTML  you  can 
specify  that  a  block  of  text,  or  a  word,  is  linked  to  another  file  on  the  Internet.  HTML 
files  are  meant  to  be  viewed  using  a  World  Wide  Web  Client  Browser. 

HTTP  (Hypertext  Transfer  Protocol) 

The  protocol  used  to  transport  a  WWW  page  from  one  computer  to  another. 


HYPERTEXT  LINKS 


146 


Generally,  any  text  that  links  to  another  document  -  words  or  phrases  in  the  document 
that  can  be  chosen  by  a  reader  and  which  cause  another  document  to  be  retrieved  and 
displayed. 

INTERNET 

The  vast  collection  of  inter-connected  networks  that  all  use  the  TCP/IP  protocols  and  that 
evolved  from  the  ARPANET  of  the  late  60’s  and  early  70’s.  The  Internet  now  connects 
hundreds  of  thousands  of  independent  networks  into  a  vast  global  Internet. 


INTRANET 

A  private  network  inside  a  company  or  organization  that  uses  the  same  kinds  of  software 
that  you  would  find  on  the  public  Internet,  but  that  is  only  for  internal  use. 

LAN  (Local  Area  Network) 

A  network  of  computers  that  transmits  data  along  a  single  shared  medium  in  a  small 
geographical  area  (i.e.  a  single  office  building  or  college  campus). 

LINK  (See  Hypertext  LINK) 

SK  (Storekeeper) 

An  enlisted  rating  responsible  for  providing  and  accounting  for  the  constant  stream  of 
supplies,  clothing,  commissary  items  and  spare. 
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TAD  (Temporary  Assigned  Duty) 

The  temporary  assignment  of  a  service  member  away  from  the  parent  command  to 
perform  duties  at  a  different  command. 

TCP/IP  (Transmission  Control  Protocol/Internet  Protocol) 

The  collection  of  transport  and  application  protocols  used  to  communicate  on  the  Internet 
and  other  networks. 

URL  (Uniform  Resource  Locator) 

An  address  or  location  of  a  site  to  be  viewed  on  the  WWW. 

WEB  BROWSER  (See  BROWSER) 

WWW  (World  Wide  Web) 

Computers  which  are  linked  and  which  provide  hyperlinks  to  Internet  resources 
worldwide. 
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